[UXPROD-3181] Local Translation of FOLIO apps static strings Created: 10/Jul/21 Updated: 07/Nov/23 |
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Massoud Alshareef | Assignee: | Massoud Alshareef |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | latam3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue links: |
|
||||||||
| Development Team: | None | ||||||||
| PO Rank: | 0 | ||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||
| Description |
|
Current situation or problem:
Excluding USA, we have three English speaking countries scenarios using FOLIO English Locale:
Use cases:
Proposed solution/stories: KnowledgeWare has developed this capability as proposed in UX-400.
How the FOLIO Translation app would handle the app static strings ?
|
| Comments |
| Comment by Massoud Alshareef [ 12/Jul/21 ] |
|
Would there be any complications in meeting the ICU syntax requirements when the Translation app is used for translating FOLIO static strings ? If by the "ICU syntax requirements" you mean to ask what if the strings to be translated are embedded with stuff like html text formats/ commands, variables to be replaced by real time values, etc., how the Translation app is going to handle them? First, it is important to point out that the Translation app does not do any strings extraction out of FOLIO apps source code. The Translation app simply picks up the object files for all supported FOLIO languages, opens up the translation column in each object file to be edited by the authorized translators, leaving its content as it has been stored by Lokalise or filled by the "Stripes-config". Peter Murray - If I misunderstood the question, please provide more clarifications.
|
| Comment by Peter Murray [ 16/Jul/21 ] |
|
I'm going to pull this out of ui-requests and put it into uxprod because this is not specific to the Requests app. One of the powerful features of the ICU syntax is the ability for languages to express different language constructs. The one I see most often in FOLIO is the use of the {plural} format code. For instance:
You have {itemCount, plural,
=0 {no items}
one {# item}
other {# items}
}.
In the definition of the Plural Format code on that web page, it describes the different ways that languages handle numbers. Some excerpts:
This is an area of localization that I didn't appreciate until I started on the FOLIO project. It isn't clear to me whether what is proposed above will meet these needs because the ICU syntax will output one string for English but an entirely different formatting string would be appropriate for other languages. |
| Comment by Julian Ladisch [ 19/Jul/21 ] |
|
I strongly disagree with this proposal of a FOLIO translation UI for all strings. It is a waste of translators time because the translations are not shared and because the FOLIO translation UI can never be as good as lokalise.com or other translation software. Translators should always add their translations to lokalise.com so that all other institutions can re-use them. The only exception should be institution specific controlled vocabulary (see list on
FOLIO is a community project, and many locales have many untranslated string. To increase the percentage of translated static strings we need to motivate and nudge possible translators to join the translation teams and lokalise.com. Making it easy to add private translations for static strings without sharing them is contrary to this goal, making it easy to join the translations teams and to use the best translation tools is the community way to go. |
| Comment by Massoud Alshareef [ 19/Jul/21 ] |
|
Thank you Peter Murray for pulling this issue out of ui-requests and into uxprod. I tried to change the issue type from requests to UX but did not succeed before. We appreciate bringing our attention to the ICU syntax requirements to comply with in Kware Translation app. Yes indeed, they are very useful in expressing different language constructs, particularly with the Arabic language since it has all six cases of the plural constructs: https://localise.biz/help/management/plurals Right now a translator with a good knowledge of the targeted language plural rules can use the Translation app as is without any problem, except that the verification process for each language plural rules still needs to implemented in the app. Work is under way to build an ICU plural rules verification system in the Translation app. We applied the Arabic plural rules on the following string, identified by the translation key "stripes-smart-components.searchResultsCountHeader" which is used in many apps for titling the search results page including the Inventory and Requests apps: Arabic translated string: "تم العثور على {count, number} {count, plural, one { تسجيلة } two { تسجيلة } few { تسجيلات } other { تسجيلة }}" |
| Comment by Dina [ 20/Jul/21 ] |
|
Julian Ladisch Allow me as a translator to share my experience here. First off, "the FOLIO translation UI can never be as good as lokalise.com or other translation software." is this a personal view or a cemented fact? If it's a view, is it based on actual experimenting with the Translation App? I have used both actually, and out of my experience as a translator, I'd like to share my experience regarding how "good" both are. Localise.com: A) Pros 1- Allows more community engagement . 2- Gives hints based on previous translated strings with a percentage of similarity. 3- Easy to use
B) Cons 1- Works perfectly with non-gender-specific languages; however, it's a living hell for gender-specific/number-specific languages, such as Arabic. The variables here are numerous, usually have to translate, then go to Folio and check the string, then go back and change the form accordingly. For example: count {plural} item could be: مادتين، ماداتان، مواد، مادة 2- Some strings don't have any info regarding their whereabouts, the translation key isn't clear enough and again due to the special nature of the language, speculation is the best option. For example: a string with one word like month(s) with no further info regarding what that is or where it is, is simply a nightmare. As far as Arabic goes, this could be: شهر، شهور، أشهر، شهرين، شهران، شهراً
Translation App A) Pros 1- Very user-friendly and highly customizable. 2- Takes into consideration the special characteristics of languages 3- Flexible as it allows exporting translations form Localise, CSVs or simply translate directly with some hints similar to Localise's. 4- Gives the ability to check the exact location of the string but hitting the info icon and get the full key which makes life easier when deciding which term/form is better. 5- Gives the option to show either the Localise translation or the institutional one.
B) Cons 1- The translations added to the APP directly cannot be shared with the community. That has been said, the APP doesn't suggest eliminating Localise, it actually helps gapping what Localise misses; hence, the community participation is intact. The user is always in control whether to depend solely on Localise by exporting its translations or use their own and that's the extra. ِ As for the claim that the App wastes translators time, it most certainly hasn't wasted mine, as a matter of fact, it saved me some time going around trying to check the string in action to decide the best form. |
| Comment by Peter Murray [ 22/Jul/21 ] |
|
Hello Massoud and Dina. I'm on holiday this week, and my time at the computer has been limited. I will be back at work next week. The community might decide to use the proposed Translations app to supplement or replace the use of Lokalise for translating apps. That is a discussion that will likely need to happen at Technical Council, and it is related in part to the ongoing plans for translating the back-end messages (
|
| Comment by Massoud Alshareef [ 26/Jul/21 ] |
|
Thank you Julian Ladisch for sharing your point of view about the viability of using Kware Translation app for translating FOLIO static strings with us. So, you strongly think that using FOLIO Translation apps for translating apps static strings is (1) a waste of translators time, and (2) it can never be as good as lokalise.io or other translation platforms. Before responding to your comments Mr. Julian, I would like to highlight the following points:
Is the FOLIO Translation app a waste of translators time if used for translating FOLIO apps static strings? I think the best judges here are the actual translators who have been using both platforms; Dina Hashing has responded to this question above. Cristina (from scanbit.net) commented during our last EBSCO Partners meeting about Lokalise by saying "we use Spanish translation from Lokalise and it's ok. I miss to get the new translations more quickly." Cristina has not used the Translation app yet. Let's look at a real case scenario and you will be the judge here. One of the most frustrating challenges facing translators is when they need to see how a translated string will sound like within the application screens so that best provisioning of the translated string can be decided on. The only way to do this is by seeing the string in the application screen while it is running. With the FOLIO Translation app you can see the string provisioning on the fly because a translator becomes a citizen to all FOLIO apps. It is the kind of feeling when the concept of WYSIWYG came about in the nineties! By the way, if you ask me about the reasons that many locales (over 70%) have many untranslated strings [current translations percentage in FOLIO static strings for example are: Deutch (57%), Italiano (65%), Spanish (65%). French (81%), Japanese (39%), Russian(37%) and Urdu (1%)], I would say look no farther than how frustrating it is for translators to go back and forth between FOLIO apps and Lokalise during their provisioning the translation strings work. These people are doing the FOLIO translation work volunteerly! If they are not rewarded for their time, that means they won't stick around for ever, specially when you consider the amount of time they have to spend on keeping up with the continuously added/ changed strings as someone would anticipate in a newly developed environment like FOLIO. On the accountability scale, if I have to chose between (1) volunteering translators (most of the time they have no library experience) and (2) the libraries which actually use FOLIO or service providers who are providing support for FOLIO, I would rather pick the second option! I will share with you our over 12years old conclusion with Koha ILS translations story in the middle east region. The number of libraries running Arabic Koha today is estimated to be about 700. We've updated the translations of over 24 upgrades/ releases during these years, most of the time shortly after the release announcement and sometime right on release date. The new English translation files are embedded within the release package, and therefore the installation of new major/ minor releases is straightforward. What we released later on is the fact that most libraries would rather stay on old stable releases than to jump on new releases coming with new features, unless they are a must have features, in spite that Koha ILS is a license free software! Come to find out the reason behind libraries being discouraged to make the upgrade move every time, is because they have spent so much time tuning the Arabic translations, at the ".po" files level where syntax errors are invited, to fit their local, in context terms. If they have to do such tuning work again with every upgrade/ update, they rather stay with the stable old version of the software without the newly added features. It is like saying: if it is not broken, do not fix it! From here, we have realized that if we make private translations easier to manage by libraries, they (libraries) will be more encouraged to keep up with translating newly added strings and/or to keep provisioning the strings context to reflect their local environment, and that will lead to loving to use FOLIO by libraries because they will find FOLIO like a home-made application empowered with the latest technologies made for the automation of library operations. Now we come to the sharing issue. You are correct, FOLIO is a community project and making it easy to add private translations for static strings without sharing them is contrary to this goal. I think the practical approach to face the sharing challenge is definitely not by motivating possible translators to join the translation teams and lokalise.com; based on our experiences described above, you cannot rely on volunteering translators to keep a large project like FOLIO, with a huge potential to be adopted worldwide, to keep it up to date with translation to all supported languages (26 so far). It is the service provider of FOLIO who must offer a multi-lingual FOLIO based solution to their local markets in order to be on the competitive edge against other LSP offerings. FOLIO service providers, FOLIO technology partners and/or FOLIO libraries implementers, are the best reliable partners for sharing FOLIO translations with FOLIO community. They (partners) are the truly always-on robust bridge between FOLIO community and their local libraries when facing all sorts of challenges, incl. keeping up with FOLIO translations to languages that have potential use in their local libraries community. FOLIO partners have the incentive to invest in translating FOLIO UI through hiring capable translators with good knowledge of library practices, and to keep their translation work always up to date, because they can add their cost to the project overall implementation and/or annual support cost. Libraries may also do their private translations/ provisioning of FOLIO UX using the Translation app, but it is the partners who will have the most legitimate reasons to share that work back with the FOLIO community. There are already over 20 FOLIO technology partners working with EBSCO EMEA (Europe, Middle East and Africa) alone. I am sure that other FOLIO technologies partners in Asia, Canada and South America will push the total FOLIO partners count to 50. It is true that the majority of these partners may only need the mono-language version of FOLIO, but the remaining number of partners are good enough to reply on to paly the mediator role for the multilingual FOLIO LSP being up to date with the translation. Can the FOLIO Translation app be as good as lokalise.io or other translation platforms ? The answer, in my view, depends on how someone may look at the circumstances surrounding the case in point: are we talking about a translation platform that serves generic needs expected by hundreds of projects, or are we talking about a platform that needs to meet a specific project needs, like FOLIO LSP, which is an open source project claimed to be made for innovation with fairly sophisticated but diversely open needs? At the end, the fact remains, no matter how functionally sophisticated a platform is said to offer, users are going to ask: what does it mean to us? We like to think of the Translation app as an environment that is created by a FOLIO implementation partner who is also getting ready to present itself as a FOLIO apps developer, and thus has enough interests to keep enhancing the Translation app based on actual FOLIO translators needs that are coming from inside Kware and also from other language translators serving the multilingual FOLIO platform. |