-
Notifications
You must be signed in to change notification settings - Fork 182
[i18n] Dashboard -- My Tasks #9750
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This puts the infrastructure in place to translate strings in loris on the PHP side using the gettext library. Japanese is added as an example (mostly using machine translation which could probably use proof reading by a native speaker.) Each module has its own textdomain for strings that come from that module, as well as a "loris" textdomain for general LORIS terms (menu categories, common terms, etc). The translations for a module are in $MODULEDIR/locale and the loris textdomain is in $LORISROOT/locale. The module names, menu categories, and breadcrumb text are currently marked up as translateable strings. This is enough to ensure that the menus and breadcrumbs in LORIS get translated. A new LORIS middleware detects the preferred language by looking for: 1. A lang=? passed in the query parameter (this can be used for testing, but does not currently have any way in the GUI to select) 2. The User's preference under "my_preferences" 3. The HTTP request's Accept-Language header in that order and ensuring that it's a language supported by the project by looking for the language_code in the LORIS "language" table. The pot files at the root of the locale directories are translation templates to give to translators. The locale/$lang/LC_MESSAGES/$textdomain.po contain the translation mapping. The .mo files are the compiled version used by the software and can be generated by "make locales". (We may want to rethink the structure of the Makefile in the future to have `make $modulename` do both the locale and javascript compilation.) Projects may override strings by putting the (compiled) gettext .mo file in the $project/locale/ directory (which would also be a good place to store the .po files). These are generated with `msgfmt -o filename.mo inputfile.po` (msgfmt is included with gettext.) Note that the format of the locale directories must be: locale/$lang/LC_MESSAGES/$textdomain.mo. We do not have any control over that. (Other then the name of the first "locale" directory, but that seems pretty standard.) It's also worth noting that, from what I've read, the *server* must have the locale installed for gettext to support the translation, not just LORIS. I don't know why. It seems silly.
This updates the "My Tasks" to handle plurals with gettext, rather than hardcoding adding an "s" in the code. Translations are added for existing "My Tasks" widgets at the same time.
@@ -21,3 +21,11 @@ msgstr "" | |||
msgid "Issue Tracker" | |||
msgstr "問題トラッカー" | |||
|
|||
|
|||
# Google Translate is giving me completely different translations for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this is your answer
No, not all languages have a clear and consistent distinction between singular and plural forms. While many languages, like English, have distinct singular and plural forms for nouns, some languages, such as Japanese and Chinese, rely on context to indicate whether a noun refers to one or multiple entities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that's the source of my confusion. It should be the same and "問題" is, but the machine translation of the "Your assigned" part is completely different based on if "issues" is singular or plural in the original English.
@@ -54,7 +56,9 @@ class TaskQueryWidget extends TaskWidget | |||
*/ | |||
public function __construct( | |||
\User $user, | |||
string $labeldomain, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
neither @ridz1208 nor I like this. One proposed change is passing something like:
class TranslatableString {
function __construct(public readonly string $singular, public readonly string $plural, public readonly string $textdomain) {}
public function getPlural(int $n) : string { return dngettext($this->textdomain, $this->singular, $this->plural, $n); }
public function __toString() : string { return dgettext($this->textdomain, $this->singular); }
}
instead of many parameters.
This builds on #9747 to add support for translating the "My Tasks" widgets on the LORIS dashboard. In the current code, an "s" is hardcoded to be added when count > 1, which doesn't work for other languages.
The signature had to be updated to include a singular and plural label, as well as the text domain that the labels come from, since they come from the module providing the widget and not the dashboard. (The dngettext call also could not be done in the module, because the module doesn't have the count to know if it's plural.)