[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: PNG File Translation app - Spanish Staic Strings Translation.png     PNG File image-2021-07-12-20-29-50-545.png     PNG File image-2021-07-12-20-31-46-025.png     PNG File image-2021-07-13-09-25-34-524.png     PNG File image-2021-07-13-10-01-45-897.png     PNG File image-2021-07-13-10-02-09-397.png     PNG File image-2021-07-13-10-20-06-499.png     PNG File image-2021-07-13-12-40-05-332.png     PNG File image-2021-07-13-17-05-58-789.png    
Issue links:
Relates
relates to UXPROD-3148 Translated library-defined controlled... Open
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:

    • Countries using English based locales and are currently supported by name in FOLIO, i.e. British English and Sweden English, but no translation is available in their native version of the English language yet, therefore the American English strings are what populate the FOLIO apps screens by default when selecting those English locales.
    • Countries using English based locales and are not currently supported by name in FOLIO, i.e. Ireland, Australia, South Africa, Canada and News Land. FOLIO users in these countries have to select the American English locale in order to use FOLIO in English, and therefore the American English strings are what populate the FOLIO apps screens.
    • Countries having their locales supported by FOLIO but their locale based translation is either empty or partially translated, and therefore the untranslated strings of these locales are currently populated by the American English strings (FOLIO original locale) by default, This is the case for translation of FOLIO apps static strings in locales like Deutch (57%), Italiano (65%), Spanish (65%). French (81%), Japanese (39%), Russian(37%) and Urdu (1%). It is the case for over 50% of the currently 26 supported languages by FOLIO. 
    • One more scenario but this time inclusive of USA libraries! What if a system librarian in a USA library wants to tweak few static strings in FOLIO because he/she does not feel comfortable about the way these strings have been formalized by the developer?
  • There are 23 countries with the Arabic language being their Official Language https://en.wikipedia.org/wiki/List_of_countries_where_Arabic_is_an_official_language 
    • The current Arabic FOLIO translation is based on classic Arabic dominated by common terms in use mostly in libraries located in Egypt and AGC (Arabic Gulf Countries incl. Saudi, Kuwait, Bahrain, Qatar, United Arab Emirates, and Oman). Generally speaking,  these libraries, or libraries in other Arab countries like Iraq, Lebanon, or in North Africa like Morocco, will have no serious issues using the classic Arabic based terms offered by Arabic FOLIO today.
    • There is the possibility that some libraries, in or out of the Arabic world, may need to change few of these classic Arabic terms in order to be in context with their local common terms. FOLIO currently supports one Arabic locale and therefore the modifications has to be done at the Lokalise translation level or by editing the "ar.json" file manually and then rebuild FOLIO again.
  • With the fact that FOLIO is under going lots of development today, it is most likely that with every app module update there will be new or modified keys for the UX terms ready for translation. This means that newly added strings will display in their app original locale (American English) if not translated yet to their locale. As we have witnessed above, translators varies in their response to newly published keys in Lokalise, and libraries relying on the paste of activities by their locale translators are prone to lots of frustrations, as would be expected if they have to go through long waits.
  • FOLIO is claimed to be the platform made for innovation. For us at Kware, we truly believe it is, and that is one of the most influential parameter that attracted us to join the FOLIO community early in the game, in 2017.  Bringing a business model similar to the model used in Apple apps store (with over 300,000 apps created today by ISVs and individuals from all over the glob) to libraries and knowledge centers, means that we better be ready to experience a flux of hundreds if not thousands of FOLIO apps coming to libraries in the foreseen future. If FOLIO apps developers are forced to go through the Lokalise route in order to have their apps supporting multiple UX locales, I think they will end up creating their own escape tools to get their apps ready for the market, avoiding the wait for any 3rd party layer which may influence the speed of their apps coming to market.  

Use cases:

  • Libraries located in countries where the English locale or the Arabic locale, to name few locales for example only, as their primary or secondary language, want to easily translate or modify existing FOLIO static strings translation found in the languages files produced by Lokalise, and to be able to store their locally customized/ translated strings in their local library installation repository. The static strings coming from Lokalise will remain untapped, so that they can be reset to anytime needed, but it will be overridden by the locally customized and stored strings during FOLIO apps UX display.
  • ISVs want to be able to localize their apps UX to any FOLIO supported languages directly, without having to go through the Lokalize route, so that they have full control of their apps road going to markets. 

Proposed solution/stories:

KnowledgeWare has developed this capability as proposed in UX-400.  

  • You can access this in Kware's FOLIO test environment here: http://folio-testing.kwaretech.com/ 
  • Username: kware_test      Password: kware_test                                    Preferred Locale: English 
  • After login, launch the Translation app: http://folio-testing.kwaretech.com/translations/libTranslations
    • Select "Applications" from the Categories dropdown list located on top of the left app pane
    • Select Spanish from the Languages filter, All apps from the Apps filter, None English from the Translation status filter. 
    • As shown in the screen below, there are only 7,387 static strings translated to Spanish via Lokalise. The remaining static strings are (11,289-7,387)=(3,902) records that need to translated. 

  • With FOLIO apps static strings now made accessible to local library and/or service providers to complete their translation/ customization via Kware Translation app, libraries  no longer need to wait for translators to complete their job via Lokalize.
  • The Translation status options below reflect how the Translation app understands the work done in Lokalise on the the static strings content. The first four options are self explanatory by their names. The last option (None English) lists those translations that are actually translated to the current locale (Spanish) by the translators via Lokalise, excluding those strings that are left empty (untranslated) and thus filled by default by the "Stripes-config" with the English strings. This is why the above screens tells us that the actual strings available in Spanish are only 7,387 records out of a total of 11,289 static strings records available at the moment in this installation of FOLIO. 

          

  •  The Translation source options allow displaying the static strings in three formats: with the strings as they came exactly from Lokalise with empty strings filled with the English strings, or with the locally translated/ customized strings by the library only, or with both strings merged together in one list with the locally translated/ customized strings, if any, overriding strings that came from lokalise, 

         

  •  This mechanism asserts that the original English strings are maintained as they are when compiled by the developers in the master strings file, and they are not accessible for any alteration whatsoever. It also asserts that the library can reset the translations, any time needed, back to their exact content when originally received from Lokalize. 

 

How the FOLIO Translation app would handle the app static strings ?

  1.  Lokalise is a translation platform, just like any other translation platform (watch out for Crowdin which is free for OSS projects), which receives files in "json" format, for example, filled with the applications' master strings proceeded with their master translation keys as complied by the app developer, and then Lokalise provides access for authorized translators to translate those master strings into the locale intended. After completing the translations Lokalise exports them into a json file format for all applications for each language, designated with the language code i.e. "ar.json", to be merged with the application at compile time.
  2. Can someone translate the master strings file directly without having to use Lokalise? Yes. You can accomplish the same task by (1) edit the master strings file, (2) replace each  English string with its translation, and (3) save the file in a json format designated with the language code. 
  3. After installing FOLIO apps, "Stripes-config" collects the translations of all apps into a single object file for each language, and that normally leads to creating 26 folders containing the translation of the 26 languages supported currently by FOLIO. At run time "Stripes-config" passes each locale-based object file to "react-intl" to present the strings in the locale selected at that moment by the FOLIO user.
  4. Kware Translation app picks up the language object file compiled by "Stripes-config" in point (3) above to present its content to the library authorized translator(s) for editing the content contained in the "translation" column, see the1st screenshot above. The Translation app then passes that object file with its translation column merged with those locally translated/ customized strings to "react-intl" for user display. This is the area where the Translation app is working.
  5. Here is a snapshot of a portion of the "en.json" file containing the master strings coming out of kware Translation app::                                                                                          "ui-translations.meta.title": "Translations",
    "ui-translations.save.button": "Save",
    "ui-translations.buttons.translate": "Translate",
    "ui-translations.buttons.editItem": "Edit",
    "ui-translations.buttons.deleteItem": "Delete",
    "ui-translations.button.confirmDelete": "Confirm delete",
    "ui-translations.googleTranslatebutton.tooltip": "Fetch translation from google translate",
    "ui-translations.buttons.translateAll": "Translate selected texts",
  6. The "en.json" file is all that is needed from Kware to provide "Stripes-config" with to add the Translation app master strings to the English object file of FOLIO. Out of the master strings files of all installed apps, the "Stripes-config" will create the English object file for all apps in the form of an object file for each language currently supported in FOLIO. Since the Translation app did not go through the Lokalise route, as expected, there won't be any translation strings available to feed the non-English language based object files compiled by the "Stripes-config", therefore what we will find is the English strings filling all slots for all the other languages strings instead.  At this point of time we only have the Translation app available in English and Arabic. If you select any other language, say Geman, for the Translation app to list all those translations coming from Lokalize in German, you will end up with a blank list, as shown below.             


 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:

  • zero: This category is used for languages that have grammar specialized specifically for zero number of items. (Examples are Arabic and Latvian.)
  • one: This category is used for languages that have grammar specialized specifically for one item. Many languages, but not all, use this plural category. (Many popular Asian languages, such as Chinese and Japanese, do not use this category.)
  • few: This category is used for languages that have grammar specialized specifically for a small number of items. For some languages this is used for 2-4 items, for some 3-10 items, and other languages have even more complex rules.

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-2802 Open ) that the institution should be able to translate within FOLIO.

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:
 
Original English string: "{count, number} {count, plural, one {record found} other {records found}}"

Arabic translated string: "تم العثور على {count, number} {count, plural, one { تسجيلة } two { تسجيلة } few { تسجيلات } other { تسجيلة }}"
 
You can test the application of this Arabic plural rules via the Inventory or Request apps' browsing filters to see the different constructs of words describing the numbers in context.

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 ( UXPROD-371 Open and Handle i18n where messages are generated (in the back-end modules). I would propose that our efforts are best spent getting the basics of the Translation app in place for the dynamic values ( UXPROD-3148 Open ) before expanding the scope of the Translation app to cover everything.

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:

  1. We have never suggested that FOLIO community needs to move away from Lokalise, or it needs to consider replacing Lokalise by the FOLIO Translation app. If the FOLIO community choses to use Lokalise today, or move to another translation platform tomorrow, or if all or part of the apps static strings translations had been accomplished manually via editing the json master strings files published by the apps' developers, the Transition app does not differentiate between the translation sources if any is found.
  2. The Translation app deals with the language object files compiled by "Stripes-config" only. It provides libraries with translating/ editing access on the translatable strings, if found, and keeps those sourced translations maintained unchanged so they can be reset/ default to anytime. Therefore, the Translation app can be used to rely fully on the translated static strings made by an external translation platform, like Lokalise, or can be used to start from zero translations, as the case with Kware Translation app localization described above. It is up to the library to decide which path is more suitable for them to follow.
  3. The FOLIO Translation app is empowered by a very robust and well tested export/ import system to enable transferring translation files between FOLIO installations at all levels, incl. the export/ import of translations at the language level, at the app(s) level, at the original strings (like those from Lokalise) only level, at the locally translated strings level, etc. So, sharing translations between FOLIO libraries is natively supported!
  4. The Translation app is made by FOLIO developers for FOLIO translators! We lived all sorts of challenges that may face the Arabic translators, and we understand FOLIO architecture as developers to make the Translation app smart enough to make live easier for translating to a complicated gender-based language like Arabic. 
  5. We've decided to extend the Translation app functionalities beyond translating library-defined controlled vocabularies, because as translators and service provider, we have realized the amount of time and efforts that have been optimized after using the Translation app, particularly for translation context provisioning, after about two years of using Lokalize for FOLIO static strings translation. 
  6. Kware is the official Arabic translation and localization arm behind the vast majority of OSS Arabic/English library projects since 2008, including Arabic Koha ILS (2008), DSpace IR 2012), VuFInd Discovery (2016), SubjectsPlus (2016), ORCID, FOLIO LSP (since 2017), and now Aspen Discovery (2021). Since 2008, Dina, Kware translation and localization director, has used very much all of the translation platforms out there, including product-specific platforms (i.e. for Koha or Drupal) and general purpose platforms (i.e. POEDIT, Crowdin, Transifex, Localise). Based on such vast experiences with translation/ localization work, I guess we are entitled to claim that we truly understand what it means when a phrase like "this is a translator's time waster" comes across.
     

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. 

Generated at Fri Feb 09 00:29:59 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.