Openfoodnetwork: Untranslated strings in front end interface

[myriamboure]

I think this has not been covered actually in the work done on business model configuration.
It seems that when I create a new store and click on the link "access my store", the page is not translated in French.

I checked in Transifex and I couldnt find the source strings, so I guess it has not been translated, am I wrong? I think the text is hardcoded, am I write? Some strings that went through our radar on the front-end translation job I guess ;-)
@mkllnk, @blancnic, @elf-pavlik can we add those strings? It's needed for any non English speaking country actually and a front end issue.

[mkllnk]

The latest translations have not been copied into the transifex branch. I will have a look why that is. I also just updated the source file. That means that there will be new translations available in Transifex within the next 24h.

[mkllnk]

@myriamboure You were right. These strings are still hard-coded in these two files:

• app/assets/javascripts/templates/admin/panels/enterprise_package.html.haml
• app/views/admin/enterprises/_change_type_form.html.haml

They have been there for a year.

Is someone keen to do the internationalisation work and open a pull request?

[myriamboure]

@mkllnk thank you for your answers, and for fixing the transifex branch :-) @blancnic do you think you can do the internationationalisation work for the two files mentionned, so that the strings can be translated in Transifex? @sigmundpetersen that also concerns Norway.

[blancnic]

@myriamboure : sorry didn't see your msg. Yes I'm going to take a look

[mkllnk]

As part of the quote for multi-lingual instances, I identified all files that still contain untranslatable language strings.

app/views/admin/enterprise_roles/_enterprise_role.html.haml
app/views/admin/enterprise_roles/_form.html.haml
app/views/admin/enterprise_roles/index.html.haml
app/views/admin/enterprises/_actions.html.haml
app/views/admin/enterprises/_change_type_form.html.haml
app/views/admin/enterprises/_enterprise_user_index.html.haml
app/views/admin/enterprises/_new_form.html.haml
app/views/admin/enterprises/edit.html.haml
app/views/admin/enterprises/form/_about_us.html.haml
app/views/admin/enterprises/form/_address.html.haml
app/views/admin/enterprises/form/_contact.html.haml
app/views/admin/enterprises/form/_enterprise_fees.html.haml
app/views/admin/enterprises/form/_images.html.haml
app/views/admin/enterprises/form/_inventory_settings.html.haml
app/views/admin/enterprises/form/_payment_methods.html.haml
app/views/admin/enterprises/form/_primary_details.html.haml
app/views/admin/enterprises/form/_shipping_methods.html.haml
app/views/admin/enterprises/form/_social.html.haml
app/views/admin/enterprises/form/_tag_rules.html.haml
app/views/admin/enterprises/form/_users.html.haml
app/views/admin/enterprises/form/tag_rules/_default_rules.html.haml
app/views/admin/enterprises/index.html.haml
app/views/admin/enterprises/new.html.haml
app/views/admin/enterprises/welcome.html.haml
app/views/admin/order_cycles/_exchange_form.html.haml
app/views/admin/order_cycles/_exchange_supplied_products_form.html.haml
app/views/admin/order_cycles/_form.html.haml
app/views/admin/order_cycles/_name_and_timing_form.html.haml
app/views/admin/order_cycles/_row.html.haml
app/views/admin/order_cycles/_simple_form.html.haml
app/views/admin/producer_properties/_form.html.haml
app/views/admin/variant_overrides/_controls.html.haml
app/views/admin/variant_overrides/_filters.html.haml
app/views/admin/variant_overrides/_loading_flash.html.haml
app/views/admin/variant_overrides/_show_more.html.haml
app/views/checkout/_shipping_ship_address.html.haml
app/views/spree/admin/products/_distributors_form.html.haml
app/views/spree/admin/products/bulk_edit/_indicators.html.haml
app/views/spree/admin/products/bulk_edit/_products.html.haml
app/views/spree/admin/products/bulk_edit/_products_product.html.haml
app/views/spree/admin/products/bulk_edit/_products_variant.html.haml
app/views/spree/admin/products/bulk_edit/_save_button_row.html.haml
app/views/spree/admin/products/product_distributions.html.haml
app/views/spree/admin/variants/_autocomplete.js.erb
app/views/spree/order_mailer/invoice_email.html.haml
app/views/spree/products/_source.html.haml

app/views/admin/business_model_configuration/edit.html.haml
app/views/admin/cache_settings/show.html.haml
app/views/admin/contents/edit.html.haml
app/views/admin/enterprises/_admin_index.html.haml
app/views/admin/enterprises/form/_business_details.html.haml
app/views/admin/enterprises/form/_shop_preferences.html.haml
app/views/admin/order_cycles/_advanced_settings.html.haml
app/views/admin/producer_properties/index.html.haml
app/views/map/index.html.haml
app/views/producer_mailer/order_cycle_report.text.haml
app/views/spree/admin/orders/_invoice_table.html.haml
app/views/spree/admin/orders/bulk_management.html.haml
app/views/spree/admin/orders/edit.html.haml
app/views/spree/admin/orders/invoice.html.haml
app/views/spree/admin/overview/_enterprises_header.html.haml
app/views/spree/admin/overview/_enterprises_hubs_tab.html.haml
app/views/spree/admin/overview/_order_cycles.html.haml
app/views/spree/admin/products/bulk_edit/_filters.html.haml
app/views/spree/admin/reports/bulk_coop.html.haml
app/views/spree/admin/reports/sales_tax.html.haml
app/views/spree/admin/reports/xero_invoices.html.haml

app/assets/javascripts/templates/admin/info_dialog.html.haml
app/assets/javascripts/templates/admin/links_dropdown.html.haml
app/assets/javascripts/templates/admin/modals/tag_rule_help.html.haml
app/assets/javascripts/templates/admin/new_tag_rule_dialog.html.haml
app/assets/javascripts/templates/admin/panels/enterprise_package.html.haml
app/assets/javascripts/templates/admin/panels/enterprise_producer.html.haml
app/assets/javascripts/templates/admin/panels/enterprise_status.html.haml
app/assets/javascripts/templates/admin/panels/exchange_supplied_products.html.haml
app/assets/javascripts/templates/admin/panels/exchange_tags.html.haml
app/assets/javascripts/templates/admin/tag_rules/filter_order_cycles_input.html.haml
app/assets/javascripts/templates/admin/tag_rules/filter_payment_methods_input.html.haml
app/assets/javascripts/templates/admin/tag_rules/filter_products_input.html.haml
app/assets/javascripts/templates/admin/tag_rules/filter_shipping_methods_input.html.haml
app/assets/javascripts/templates/out_of_stock.html.haml
app/assets/javascripts/templates/single_line_selectors.html.haml

[pacodelaluna]

@myriamboure I can take a look at this issue, I will start right now.

@mkllnk Is there any pattern to follow in order to add translations keys ? Actually I can't see any one but maybe I missed it.

[Matt-Yorkley]

@pacodelaluna If you look at the en.yml file, some of the keys are grouped like this:

admin:
    enterprise:
         example: "Example translation"
         example2: "Example translation 2"

The key could then be called like this: t('admin.enterprises.example2').

As a side note for anyone adding these translations, there are existing translation keys already for most of the fields in the files under app/views/admin/enterprises/form/, you can find these in the relevant templates under app/assets/javascripts/templates/registration/.

[mkllnk]

@pacodelaluna You will find good examples and outdated examples in the code. If you translate something in app/views, it is a good practice to use relative keys. For example, the file app/views/admin/customers/index.html.haml contains this line:

= t('.duplicate_code')

The period in the beginning of the key means that it has a relative scope. The translation key for this in en.yml is:

  admin:
    customers:
      index:
        duplicate_code: "This code is used already."

That gives the file a nice structure, avoids conflicts and keeps the view files a bit cleaner.

[pacodelaluna]

@mkllnk I totally agree on following the convention for this, so I will start doing this on admin side.

[pacodelaluna]

@mkllnk @Matt-Yorkley I have made a commit which is mainly setting up all the missing i18n keys on Admin side, it is here: https://github.com/pacodelaluna/openfoodnetwork/commit/7dd4b3eedba07f884531ff2e87e5dcc3b6854760.
I still need to tune up the tests but please tell me if there is already any issue.

[elf-pavlik]

Looking at that commit I think that it seems very strict about keeping keys in scope and may require more work when translating?

I see name: Name 12 times, will people doing translation need to translate the same simple string 12 times? Same with owner: Owner 4 times etc.

[mkllnk]

Good question @elf-pavlik. Transifex has a translation memory that could help with these strings. But I'm not sure if it can do it within the same translation session. That is something to test.

name is a global key already and can be re-used. It just has to be in a scope when it has a different translation. For example, in one scope it could be "full name" and in another scope it could be "enterprise name".

What would be a good rule? I think that 1-3 times the same translation is alright. If you find the same text in 4 or more places, a global key is probably better. What do you think?

[pacodelaluna]

@elf-pavlik @mkllnk First of all, thanks for your feedback. I got your point about duplicated keys and translations, and it can really looks as an issue to translators initally, but it can also give them some power at the end to customize the messages. Still I will try to refactor code and use more generic translations, which I am actually doing on some parts actually, but I don't hink that the 'name' key is such a good example for the reason @mkllnk mentioned (We already have the issue in french).

[elf-pavlik]

I got your point about duplicated keys and translations, and it can really looks as an issue to translators initally, but it can also give them some power at the end to customize the messages.

I think when adding new scoped key, reusing some 'global' key or creating new 'global' key, one needs to think how likely it will need customized translation for the scope.

I also think when need to customize a message arises, someone can patch the code 'on-demand', and possibly we shouldn't worry about possible customizations to early. Also if we have multiple scoped keys for something that one expects as the same translation, to update this translation it will require updating all those 'scoped' versions.

Again, I think we can't have easy answer here 'scope' everything vs. reuse everything and it may require case by case judgement keeping pros and cons in mind.

[pacodelaluna]

@elf-pavlik I totally agree, there is no best solutions on i18n, pros and cons for each methods. I have just followed the method suggested 2 days ago, when I was asking for a pattern on i18n keys.
I have refactored a bit trying to use more existing keys, especially on 'address' side and on 'enterprises/new_form', here https://github.com/pacodelaluna/openfoodnetwork/commit/27cd145caea99398af3b9abfc34bf70d8494f665. Just tell me if it is ok for you now or if I should adapt more.

[pacodelaluna]

@mkllnk @elf-pavlik Can I create a PR with this commit ? Should I integrate the keys into Transifex now or after merging ?
I have still issues running the tests locally but I am quite confident as manual checks were good locally and I am only modifying the views. I wish to go on this topic asap as there is potentially rebasing with this commit (as it is touching many views).
Tell me if any issue.

[elf-pavlik]

LGTM but better wait for @mkllnk opinion...

I have still issues running the tests locally but I am quite confident as manual checks were good locally and I am only modifying the views.

Have you configured Travis CI to run tests for your fork? This way you will see if all tests pass even before you create PR

[mkllnk]

@pacodelaluna Yes, please open a pull request. Rebasing on the current master is a good idea.

[myriamboure]

@pacodelaluna can we close that issue ? Did you go through Maikel's list of untranslated strings ?

[pacodelaluna]

@mkllnk I have made a last check and correct few missing translations, here is my commit, https://github.com/openfoodfoundation/openfoodnetwork/pull/1643. I am not sure everything is done, but at least 90%, so we could close this ticket after merging this last commit.
Tell me if any issue.

[daniellemoorhead]

@mkllnk given the PR has been merged can this issue now be closed?