As some of you know, Lentschi and I have been working on a big upgrade regarding article unit handling in Foodsoft: Among other things, we want to introduce predefined units from the UN/ECE standard.
For further details about the project, see the matrix room (posting from June 2023).
The UN/ECE standard only provides English unit names and symbols, no translations. That’s why we need contributions from native speakers of other languages:
German – done
Dutch – needed for sure
French – does anyone know if there’s a French user community?
Spanish – does anyone know if there’s a Spanish user community?
Turkish – does anyone know if there’s a Turkish user community?
Dutch locales
We would need these spreadsheets to be filled out:
We’ve made a selection of 117 scalar units which we could imagine being useful in the broadest sence. Other units from UN/ECE can still be activated by request, but we won’t add any translations for them (unless someone provides them).
Please either replace or clear all yellow marked cells in the nl subtable.
Short names and symbols are important. We’re not sure if we’ll use alternative symbols yet, so don’t put too much effort in those. Same for full name and description – these will only appear in a menu where you can manage the activated units.
This is the full unit list from UN/ECE Annexes V + VI (coded representations of package type names used in international trade). We’ve made a selection of units which we find useful and would activate by default. These are marked with 1 in the first column, so they are most important. You can filter by this selection. (For German, I’ve translated the full list, but concentrated on good translations for the selected units.)
We aren’t sure if we’ll include abbreviations in the first implementation. Don’t put too much work in here.
I’ve copied the German names to MS Word, used Word’s feature to translate the whole document to Dutch, then copied it back into the spreadsheet. This worked best for me when translating English to German. Of course you have to go through manually afterwards. Perhaps you know a better AI solution. (I could do this for scalar units as well in case you don’t have MS Word).
@decentral1se Could you do this or forward it to other members of the Dutch community?
I think it’s great of the Dutch community could give this input (it’s something also non-developers can do), but if that takes a long time and you need to get forward, feel free to ping me and I can have a look.
The users list on the wiki does show a French group, you might try contacting them.
For other languages, perhaps looking who contributed the locale files and/or on edited a language on crowdin.
heyyyy, this is still on my radar as I try to build the systems workgroup in the local food coop to pick it up hopefully some news in this regard Coming Soon ™
It was interesting to learn about all these packaging terms and scalar units outside of the metric system. In Dutch language there may exist a formal translation, e.g. “inch” → “duim”, but because no-one uses those, it would only cause confusion. Therefore, I applied the following translation-logic:
Scalar units.xlsx (43.2 KB)
If a unit is known to Dutch people in an American / British context only, I keep the original name with country suffix in brackets. e.g. “foot” → “foot (Engels)” with abbreviation “ft (UK)” (instead of confusingly translating “foot” to “voet” and having no sensible abbreviation that matches “voet”).
Piece units.xlsx (49.6 KB)
When an item refers to a specific name for a shape or size, e.g. a demijohn bottle or English brewery cask units like tun, butt, hogshead, tierce or barrel, I used a generic Dutch translation for the class of vessel with (country and) original name suffix in brackets, e.g. “carboy” → “mandfles (carboy)” and “firkin” → “vat (Engels: firkin)”. This was needed for only a few items in the selection, but I was enjoying the process so I translated the whole lot.
Also note that I have not capitalized the first letter of each item (which was done for the English and German), since these words are likely to be placed behind other words. Capital letters were used exclusively when gramatically needed e.g. for “Amerikaans” / “US” and “Engels” / “UK”. Therefore: do not apply lowercase-function when inserting these translations, and certainly not for unit abbreviations (“M” for mega will become “m” for milli). For German this is even more relevant because proper nouns are supposed to always start with a capital.
A few things I noticed looking at your translations:
There shouldn’t be two units of the exact same name, since this could lead to unwanted changes when exporting & importing via CSV: You’ll be able to just write the unit name (locale) in the CSV and the first matching unit will be selected.
Sorry I missed to note that beforehand, it wasn’t clear how we’d handle this when I first posted it here. I’ll have to adapt the English & German locales as well.
Tip: In the German translation, I used that chance to include alternative names for the same unit instead of always choosing the most precise translation. For example, “bin” and “bucket” both translate to German “Eimer”, so I chose “Kübel” for “bin” to have the variant “Kübel” in the list, instead of translating one of them to a cumbersome “Eimer (bin)”. You might want to do that as well.
kop (Engels): Is the “(Engels)” really necessary? Since it’s a piece unit, it does not refer to the measuring unit cup, just as a delivery unit.
Good point, I’ll adapt that for the English locales when you are done.
You are right about the container “Cup”. This should not be the unit cup: “kop (Engels: cup)”, but instead it could become “beker” in Dutch.
Some other cases will become tricky, using uncommon words, or they are context-dependent, eg. a bar of soap (stuk zeep) vs a bar of chocolate (chocoladereep) vs a steel bar (stalen staaf)… I think I need a drink
Please help me better understand what is the intended use of this list. You describe “exporting & importing”: to / from where? You describe “first matching unit will be selected”: matching to what? Is “translating between languages” the purpose, and if so: why? are goods not entered into each foodsoft instance based on what their suppliers provide? eg. our supplier sells a “sixpack” of beer, but the list contains no packaging entry for “sixpack”. How will a user interact with this list?
Finally, if you limit the piece units list to the “selected” rows only, there are actually no duplicate descriptions in this updated file: Piece units.xlsx (49.7 KB)
Spreadsheet file ↔ Foodsoft.
You know the spreadsheet upload feature as in here?
I’ll send you a link to a video via PM that explains the new features (was also posted in the Matrix room, don’t know if it would be okay for @lentschi to post it here publicly)
In case of “sixpack”, you could either use a custom unit or choose package, crate etc. Among the new features you can specify that a package – or any (custom) unit – of said article contains e.g. 6 x bottle and a bottle contains e.g. 500 ml.
I’m not sure how the import would handle sixpack at this state. I hope it would just set a custom unit sixpack. Actually we wouldn’t need the custom unit column then.
The export/import usecase I mentioned would be: You export a CSV to edit the articles as a spreadsheet and import it back afterwards. If there are multiple units of the same name, the unit might get changed unintentionally.