That is in the admin panel. If you edit an order, you can do adjustments to each item (product). That page shows the included tax for that item and you can choose to remove the tax or choose another tax category. Since you can define your own tax categories in the system, you need a general word for tax. If the item is a vegetable, the tax might be different to alcohol or a service.
These words are not visible to customers.
Hey @maikel I updated the translations of the 2 last sentences in Transifex from VAT to a general wording for tax. This is for the Norwegian file so it will have to be merged again.
Thanks @sigmundpetersen and @MyriamBoure for translating. I got something new in place: Transifex GitHub integration. One of our servers gets notified everytime you complete a translation and pushes it to the transifex branch. That makes the latest translations visible to the public and you can deploy that branch if you want to get the latest translations. We can update that branch whenever we release a new version.
Our transifex branch got updated to the new release v1.3. Since that release introduces changes in the user interface, new strings need translation. Most languages are missing around 89 words at the moment. Once they are at 100% again, we will make a new release including the translations.
Hi @maikel and @MyriamBoure, I found an un-internationalized string in a file (stil in plain text instead of using the t option). The process for submitting the fix is not clear to me
THanks for clarifying.
Hi @marito59, please don’t change the transifex branch. We use it to synchronise Github and Transifex on release level.
Best practice for any contribution is to create a new branch based on our master branch and submit a pull request. Your changes would then go into our master branch and into the next release.
We would like to get the current release translated completely before we start translating the next release.
Does that help? Where would you expect to find this documented?
Hi @maikel and thank you for all that job! Great to see the platform in French & Norwegian 
I have a question for the back office, I had understood that people had worked on it during the hackaton so that the back office can also be translated, am I right @Selmo and @elf-pavlik? I was just wondering about what is the next step on that. Thanks for the info!
Thanks @maikel. I’ll do as you suggest.
However, wouldn’t it be better to have a branch for translation in order to have 2 different persons changing the code at the same time. I really depends on how quick the PR is processed.
On your last question, I will start a discussion around development in a separate thread, since a lot of questions are raised now that we are using more extensily the platform. I’ll ping you.
Could you also check that I have the rights to do PR, the Github client seems to reject my commits and sync. Same for Issues, I can’t add labels to an issue I’ve created.
On the other hand, it would be annoying to translate a string that isn’t
used in the master branch anymore. Or to translate something that is
changing which causes a conflict.
I think the solution would be a quicker review of pull requests. You are
very welcome to look through pull requests and give your opinion.
Hi @maikel! On my question about internationalisation of the back office, I have added an example in the GitHub issue: https://github.com/openfoodfoundation/openfoodnetwork/issues/774. Ping @Selmo after our discussion on that topic
So if I understand correctly (from #753 and #774), the work on i18n done during the hackathon is yet to be merged with master, awaiting its completion from @elf-pavlik.
So before @marito59 and @nickwhite get into the details, they should make sure to check the PR in #753 on what’s already been done. But they probably already understood that and it’s just me who’s now waking up… 
@maikel, @MyriamBoure, @Selmo (and pinging @nickwhite),
Let me give some explanations:
We have found 2 cases that are different and are not related to translating strings in Transifex:
for case is #774 as referenced by Myriam: the issue is a Calculator class Weight (per kg) in app/models/open_food_network/calculator/weight.rb where apparently the name that is used in the select is coming from the def self.description piece of code for which I am wondering in the issue if we can just use =t some.translation.entry to get the translation from the local file. I am not that familiar with Ruby to be sure that we can just do that, therefore my question in the issue.
the second example is the translation of strings in momentjs-rails. @nickwhite have a fix that works for us but should certainly be reviewed by yourselves. here it is:
in all.js.coffee in app/assets/javascript/darkswarm,we add all required languages but english in the form of #= require moment/fr.jsand in app/assets/javascript/darkswarm/filters/dates.js.coffee we insert moment.locale(window.I18n) before moment(date).from_now().
Do you agree with these fixes, at least on the principes ? In that case, we will publish the file in a PR for validation.
Ah, thanks for that. I think you should do two separate pull requests.
Altering weight.rb: You can use the t function anywhere in the code. Spree does it here: https://github.com/spree/spree/blob/master/core/app/models/spree/calculator/flat_rate.rb
Your code always includes fr.js. That is only useful for French instances. We need a solution that includes the js file depending on the locale. Apart from that it looks good. Definitely the right way to use the localisation of the moment module.
Hi,
We don’t need to add moment.locale(window.I18n), require moment/fr.js it’s enought. I agree with you @maikel we need to separate this locale in a locale js file for example and included in the gitignore…
@blancnic Is it possible to use the default locale during asset compilation? Something like #= require moment/#{I18n.default_locale}.js.
Or can we load the locale dynamically? For example, have a line like this in the view:
= javascript_include_tag "moment/#{I18n.locale}.js" unless I18n.locale == :en
Hi @maikel, (and adding @blancnic, @RohanM and @pmackay to the discussion),
Following the discussion, we have different options:
all.js.coffee file using ansible via ofn_deployment depending on the configall.js.coffee, is not allowed as far as I understand. There is no way to use a variable or a condition in the asset pipeline.My personal choice would be thru Ansible as long as it is the uwual way to deploy.
Any thoughts ?
We are using Ansible to provision servers, but have a different method to deploy/upgrade. I think that the dynamic inclusion is the best option. Also because there will be countries that want multi language support. In that case the user will change the language and we need to load the locale dynamically or include all supported locales.
OK, I guess we are talking about a new feature : ability of the user to switch language.
Is this feature planned somewhere in the release plan, yet ?
I will investigate further with that option in mind and see if I can get somewhere. I’ll let you know.
The development notes of the internationlisation project had that in mind. But that feature was not included in the first round.
So, if we do internationalisation work and it is not too hard to keep it flexible for that feature, it would be good to go that way.
Yes, to be able to switch language within one instance is something that might be required soon… we were discussing that with Indian people recently, they have 24 languages I think