Sounds like you have some amazing and highly relevant experience @tommy.hagvall! Time is a factor obviously though and we’re wanting to start sharing WGACA in the real world ASAP (I’ve already started with real neighbours here in London).
If you’re able to help with Swedish localisation that would be immensely helpful, thank you. Can I suggest you get in contact with @aldo.ercolani in the first instance? He’s also working with a senior Dutch Pythonista so hopefully between the three of you, you can not only create three local language versions of WGACA but build a framework that makes it easy for other volunteers to create even more versions quickly and easily. I think the exercise might also be a good way of showing you around the internals of the code, after which I imagine you’d have a million suggestions for improvement!
Another repeating challenge for local versions of the app is going to be the creation of an address dictionary for the signup form. Each country might have slightly different datasets - I’m almost finished automating the process of scraping County-Town-Street combinations from 800+ spreadsheets from the UK’s Ordinance Survey data set. I did start looking at global datasets, online services, and tools like Geopy and Pelias but there are local quirks that I think are best left to local volunteer developers rather than trying to force a one-size-fits-all solution.
My current thoughts for WGACA address data are:
We need to standardise address data when a user signs up, otherwise matching Offer and Request addresses gets difficult.
The basic internal structure is a nested dictionary of Country, County (or Borough/State/Department/District) - sometimes combined for simplicity and to avoid hierarchies of different depths e.g. “Wandsworth, London” for the London Borough of London in Greater London, Town (or Village, or City), and finally a list of Streets. House Name/Number and Postcode are provided by the user since they’re sometimes incorrect on public databases.
I did consider making API requests on services like Google Maps, Photon, or OpenStreetMap, but with potentially huge numbers of WGACA users didn’t want to spend time with API keys and getting around quotas etc, so the pragmatic approach for now is for each local version of the app to have its own prepopulated ‘database’ (Python dictionary… or import directly into an Anvil data table) containing the address hierarchy.
House Name/Number is only shared with the volunteer Runner once a delivery job is confirmed. “Need to know” privacy basis.
Postcode is deliberately not mandatory and therefore not relied upon in the code. The (rudimentary) matching is by County-Town combination currently and this is also sufficient to convert to Geocode (in progress) to estimate distances and pop up a helpful map. Postcodes are shared when authorised by the person making, or receiving an Offer.
Finally regarding ‘pricing’, my intention was to run this as (my first ever) Open Source project with the deliberate aim of encouraging up-take in the community. Having said that, I was wondering about putting a Donate Button in there (with Stripe, which you mentioned) so people could, if they want to, encourage and thank each local developer (and other selectable local charities) for their time and give them the financial head-space to offer even more time making improvements and keeping it all working (e.g. providing support and data/code updates etc).
Hope that makes sense, and sorry if I’m rambling! Basic please we’d love have your help, and @aldo.ercolani would be a great first contact.
Yes I think it makes sence and now I understand more of the intent, aim and ambitions that drives the effort of engagement. I am interrested in giving this a Swedish spin. Can I get a moment of introduction from @aldo.ercolani what he did for his area - that would be very helpful.
Hi @tommy.hagvall and @AWSOM
I was assigned 3 tasks by Peter at first but in the end I did not contribute to any of them.
Peter and I agreed on a change of plans, in part because we struggled trying to figure out how to effectively teamwork, in part because we needed to clarify a lot of open points in tasks #8 and #9 and last but not least the time I could dedicate to the initiative revealed not to be enough to meet Peter’s plans.
So in the end I did nothing of the three tasks initially assigned to me, and focused on having an italian-translated version of the APP released by Peter.
That said, Peter and I agreed that translation was not to be done “by hand”, but it was the right occasion to build some kind of translation tool.
I am focusing on that now.
The idea is basically this: each person willing to translate WGACA to another language starts by cloning the “reference” APP published by Peter.
Then translation takes two steps:
1.translating APP’s YAML file
2.translating all text strings written inside *.py source code. This second point needs a clean approach by the python coder, who should place all “language sensitive” strings in a separate .py source file. Otherwise, the hunt for strings in source code is a tough one.
I am now focused point 1)
The translator downloads the YAML file, uploads it into the tool.
The tool will parse the file and present the translator with a view on the strings keys, with enough context on APP / form so the translator can provide a good translation.
Translation will be stored in ANVIL’s Data Tables, so that subsequent editing of the same file will match APP/form/key and retrieve already available translated strings.
The tool will produce a translated version of the inpu YAML file.
The developer will upload that to Anvil.
The same approach could fit point 2)
But again, I am at a very early stage of it, having just found some YAML parsing python library and made my first tests with it.
Unfortunately, the time I can work on this is so small.
As for the experienced Dutch python developer Peter was talking about, I’ve not yet been contacted at all.
Maybe I missed his emails?
Thank you for sharing @aldo.ercolani.
Good input for me right now. I was about starting doing it manually …
I have in the past done similar stuff in translating to Swedish and it have been propertyfilebased and more recently jsonfilestructures. YAML i use a lot for other puposes. I use YAML in the area of cloud deployment but also YAML for describing Restful API endpoints.
Is the part of creating that first baseline of an English source of a vocabulary being the attribute to be mapped to another language. Is that structure completed ?
The other area which is more difficult I assume is finding all the hardcoded values and replace then with some variable statements instead.
Once those are done the easier part will be enabling more languages by adding more YAML files.
I am very interested to get your first draft just to glance through the naming convention.
Realistically I’m not going to have much/any time to restructure the English that’s already inside my .py files so I think we have to be pragmatic here…
I was thinking of a list of mappings to intelligently (and hopefully safely) search and replace.
For example replace print("Hello_World") with print("Ciao_Mondo").
The fact it’s inside a print statement gives some level of reassurance that it can be safely replaced with a local language variant, whereas if you’d just globally replaced Hello_World with Ciao_Mondo you’d also possibly be changing any objects named Hello_World - which might be helpful for the local developer but I think it’s better to keep the code itself in English as a master reference, otherwise merging future versions is going to be a pain.
I’m learning as we go along, so I look forward to seeing what you come up with…
I like your thinking Stefano! Taking it one step further I imagine we could over-ride the print function to do the lang[string] lookup and save ourselves some editing.
from lang-it.py import lang
original_print = print
def local_print(expression):
if type(expression) == str and expression in lang:
original_print(lang[expression])
else:
original_print(expression)
print = local_print
Then:
>>> print("Hello world")
Ciao Mondo
>>> print(40+2)
42
However print isn’t the only place local language will appear, especially in Anvil where most output is set by calculation then changing .text attribute etc. . For example the status of an Offer or Request in WGACA might be something like this:
count = len(offers)
label_1.text = f"You have made {count} offers. Very generous of you!")
Hence my suggestion of search and replace e.g.
lang = {'label_1.text=f"You have made {count} offers.Very generous of you!")' : ' label_1.text=f"Hai fatto {count} offerte. Sei molto generoso!")'}
I’m not sure if this sort of case is already covered in https://anvil.works/library/localisation but I need to step back now and focus on priority fixes and enhancements for WGACA. Thanks for contributing and I hope @aldo.ercolani and @tommy.hagvall will be able to move this forward from here…
It is great to see this project is attracting so much attention and collaboration! Love it!
However, I think it is time for further discussion of this project’s development to be handled outside of the Anvil Show & Tell board. Interested folks could contact @AWSOM directly and specific coding questions can always be posted to the Q&A board.
Agreed that this is impressive progress – and also that it’s probably time for this project to find a space of its own.
If you’re looking for free places to host your collaboration, I can suggest Google Groups for forums/mailing lists, or Slack for chat, combined with GitHub issues, Google Docs or Trello boards for recording decisions. (Those are the tools we use internally, and they work well for us.)
I’m happy to leave this thread open so you can pick a venue, post links so everyone knows where to go if they want to help out, and generally migrate in an orderly fashion
Also, to be clear: Please do keep asking questions in Q&A, requesting features in Feature Requests, and showing us what you’ve built in Show&Tell! We just don’t have room for every Anvil project to do their project management on here too.
Yes very sensible! As you say this is for Show and Tell (and hopefully getting a few volunteers involved - which it has I’m delighted to say), not for project managing it.
If you could just keep it open until I’ve setup a Google Group or similar this weekend and posted the link that would be great thanks.
PS I’ve lost my ability to edit the initial post - so might need to beg a favour from one of the moderators, thanks.
A very simple and easy solution would be to bind the 3 word addresses provided by what3words to your User_ID’s. Otherwise a custom GeoJson parser/validator?
I would argue that the vast majority of prospective users would prefer using a modern, interactive map interface over having to search for their postal code. I would strongly advise ArcGIS/OSM/GMaps. Following is an excerpt from google for reference to your cost concerns;
It is going to take months before the App reaches those levels of traffic, and you can set it up from the start with rate limits, so the mapping service is essentially free. This solution can be implemented using these HTTP Endpoints for web services.
