Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-3181

Local Translation of FOLIO apps static strings

    XMLWordPrintable

Details

    • New Feature
    • Status: Open (View Workflow)
    • P2
    • Resolution: Unresolved
    • None
    • None
    • None
    • None
    • UXPROD features
    • None
    • 0
    • 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.             

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                massoud Massoud M. ALShareef
                massoud Massoud M. ALShareef
                Votes:
                0 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                  Created:
                  Updated:

                  TestRail: Runs

                    TestRail: Cases