Two new, experimental localization files (attached) have been added to the collection of localization files: Italian and Polish. Both are the result of an automated process using Google as described in this post.

The main virtue of these files as an experiment is the unprecedented speed with which a translation to a new language can be done, about one hour from start to finish including all tinkering. At the same time, the artificial intelligence Google uses for translations has gotten much better than it used to be, so the results of that translation appear to be useful.

These two localizations are intended as test cases for two purposes:

First, to see if automated methods have become good enough to produce a useful localization at very low investment of labor. The main interest is top level use by a wider range of less advanced users, including Viewer by many people and Manifold as a GIS by those who need some support in their own language and find it difficult to work only in English.

Second, to see if having such initial, automated translations will make it easier to create human-edited localizations. I suspect it will, since starting from zero may seem overwhelming, but if one disagrees with a particular word chosen for, say, "Layer," it is no big deal to do a search and replace in the localization file to substitute the word you prefer.

I think the first purpose is very important, because much of the data on which decisions worldwide are made is geographic data, including imagery and other information that often is too large or exists in formats unusable by small packages that are widely translated. Extending the range of localizations to many languages used in developing countries (use any search engine to see the 100 most used languages by the total number of speakers) would allow more of those populations to use Viewer.

Viewer is especially useful because it is small, it fits into 32 bit devices, and it provides access to an extraordinarily wide range of different data. As an enabling tool, it's great for populations in developing countries.

Attachments:
ui.it.txt
ui.po.txt

Whoops... there was a typo in the Polish file name. It should be ui.pl.txt (attached). The correct one is on the website, tec.

Attachments:
ui.pl.txt

It is great to hear that Mfd is excited about the prospects of Viewer being a tool for the masses to consume GIS data. I'm hoping it will be great for allowing a user to explore datasets they find on there own or for allowing a GIS user to set up a project that is customized for them.

Here's some thoughts (all has been discussed before) that come to mind about what would help.

- Easier table exploration

- Avoid having to create a new drawing from a linked database in order to style it.

- Something like Rich Text Format, so we can put together more attractive "How to ..." instruction comments.

- Allow setting up a startup arrangement of components, map zoom location, and panes.

- For those without access to a GIS person with the license, perhaps Mfd should make a few downloadable projects with sample data (aerials, roads, etc.) and instructions. These would allow people to avoid having to reset up the project every time they use it. Maybe this exists already. It could motivate them to try and find the data where they live or get into mapping.

Anyway, glad to see your post.

Thanks, Mike, for the ideas and the encouragement. Some questions/comments...

- Easier table exploration

What did you have in mind for the above?

- Avoid having to create a new drawing from a linked database in order to style it.

You don't have to do that now if you have write permission in the database and permissions to create tables in the database. See the Example: Link GPKG and Save Style topic.

That's a very clean solution because the style is saved within the database, so it doesn't matter if links get broken or if the drawing is opened from a different computer. If you don't have permissions to save stuff into the database, then there has to be a way to save style info within the project in a way that maintains a link to the database.

That's obviously more fragile and project dependent, but it also requires user interfaces that have to be understandable and convenient to both learn and to use. If you have some sort of phantom style storage that isn't visible to the user but is created on the fly to give the impression that the drawing within the database is styled, that involves a lot of user interface and storage infrastructure which just ends up duplicating, but in a different way, what is already there for drawings. Creating a linked drawing uses exactly the same infrastructure (properties, etc) that's already in place, so no additional infrastructure to build or additional UI to learn.

I'd suggest an adjustment to the above that would simply make it easier to create a new drawing within the project from a linked database in cases where the linked database does not allow you to style it. For example, you could right-click on a drawing within an external database and choose "Create Local Link", and a local linked drawing would appear. (I'll send that in as a suggestion...)

I've sent in a suggestion for a similar thing with image servers, where I'd like to see the built in image servers have a "short name" by default, and whenever you create an image server data source it automatically creates a linked image within the local part of the project using that short name. That would greatly shorten the names used on tabs, so you could have "Bing Streets" on the tab instead of the current, long, fully-qualified name, and you could also style that layer.

Mfd should make a few downloadable projects with sample data (aerials, roads, etc.) and instructions.

There's something like that in the Examples page (same list repeated in the Viewer and main downloads pages). If what you had in mind were "raw" projects with pre-built maps with image server backgrounds, those would be easy to do as "starter" examples.

What would you recommend?

By the way, on translations, it will be interesting to see what reactions there will be to the semi-automated Google translations. It may or may not be enough, but already it's clear Google has made big progress in the last two years.

As Google's AI gets better and better, I think we'll be close, maybe in a year, to the point where Manifold itself could automatically pull text out of the current tag=text system and run it through Google's API to translate it into one of the many languages that Google knows. You could then launch Manifold and if you wanted to see the UI in Urdu, just pick that and it would happen automatically.

We're very close to that. All we need is some "do not translate" marker so some tags can be marked as not to have any text except that within <> brackets translated, thus allowing fully automated translation that wouldn't touch SQL or $ literals. (I'll send that in as a suggestion...).

The Create Local Link idea sounds like a good plan for Viewer users. To help these folks, it should be clear what is read-only and what isn't. Maybe some sort of icon change for the component. Not knowing a table is read-only will be frustrating for new users because they won't understand why some things don't work or how to fix it.

Regarding the table, I think it needs to show how many records are in the table, how many are fetched, what is filtered, and how many are selected. This could be displayed along the bottom or perhaps in the info tab.

Also, it would be nice to have a means to save and modify selection steps, so that as your exploring the data you have the ability to modify/recreate the selection. Sort of like saving image modification steps in photo software.

For sample Viewer projects, maybe just create a few for specific areas/states/countries and then others can adapt for their areas. For Colorado, USA, I'm thinking Google imagery, Google street map, USGS scanned topo maps, and a comment that links people to the state GIS page where they offer data downloads. I deal with local data 95% of the time, so not the best guy for this.

Getting address, road, land ownership, and places data is the backbone for many mapping projects. Just some helpful hints on where to track this down for an area would be useful. How to work with OSM data would be good as well. Also, if a cool bit of data is available for an area, include it to show the process and motivate.

Viewer project can also show how to organize the project tree to keep things tidy when component numbers grow. To that end it would be great to have multiple ways to view the project tree. The filter option is really great but sometimes you don't know the name but you know your looking for something that has lots of data, a big extent, recently added, etc. Adding a means to order by these parameters temporarily would help.

I think these attempts at "localized" interfaces made by foreigners are wholly and utterly misguided.

No foreigner knows the local language--let's just say, AT ALL--without having lived in the country for at least some of their formative years.

It's not a graduated thing, it's absolute. Functionally yes, you can know a language a bit but not much.

But definitionally? No...

You either belong or you don't. It's that simple.

Bringing Google code into the picture, well that is just stupid.

Sorry Dimitri but please, you're making a fool of yourself by making a fool of real, vital, living languages.

I agree with you thjb. Even today the automated translations are far from good enough. To convince myself I followed Dimitri's steps for the dutch language. At first glance it is not that bad, but a closer look reveals terrible mistakes that triggers a lot of irritation and confusion. E.g. the word ORDER in the sensor of which comes first is translated into BESTELLING, which you do with a pizza!

Many sentences are technically dutch, but completely meaningless.

At least all the time I spent while translating was worth while, and can not be replaced by half an hour cut and paste and Google.

Google Translate by the way is a very useful tool. It regulary came up with translations that I hadn't thought of.

http://www.mppng.nl/manifold/pointlabeler

Strongly disagree, Tim. Don't let the perfect be the enemy of the good.

Automated translations by Google are used by hundreds of millions of people every day. Translations of web sites have expanded access to knowledge published in English for billions of people who do not speak English.

On-the-fly audio translations by smartphones have revolutionized travel (or did, before current travel restrictions...) for millions. Anybody who's travelled a lot has witnessed plenty of cases where people who don't speak one word of the language in a country they're visiting will travel about just fine using their phone to translate conversations with taxi drivers, hoteliers, asking directions, and the like.

Automated translations are a key part of our world. They're not going anywhere, and they're getting remarkably better. In fact, they already often feature better grammar, choice of words, and spelling than some poorly-educated natives.

What powered that mass utilization of automated translations I think is that getting the gist of a foreign text is often very valuable, so valuable that it matters less to the user that the translation is imperfect, at least as compared to having no translation at all.

In the case of automated translations for user interfaces, it doesn't take much translation at all for the words found in top level menus that are most often used by beginners. Having such top level commands translated to Google levels has two benefits: first, it helps people get started using the program who are rank beginners (not a lot of sophistication required for entry level Viewer users), and second, it provides a starting point for better translations by native speakers.

Slamming Google for doing a terrible job is not fair. When I compare what Google writes in the case of languages where I have native fluency, it's rare that I see a translation I completely agree with. But, it's also becoming rare that I see something which is wildly off to the point it sends people in the wrong direction. And almost always, it's convenient when I'm manually translating to start with something Google has translated and then edit that starting point into what I want. That's usually quicker than starting from scratch.

The last point is that Google is getting much better. If today's automated Google translation is not better than nothing for beginners (I doubt that, but say that's the case) then it is only a matter of time before it is. At the rate Google are improving, as can be seen by examining the quality of Google translations in languages where you have native fluency, it could be a matter of months, perhaps a year or two, before Google automatic translations will be much better than nothing.

Keep in mind that text like File - Open and so on isn't Shakespeare. It's brief, technical words and phrases that often in and of themselves have been picked as a matter of taste or are made up words. Artificial translations of those are not an assault on, say, the rich literary history of Italian or Polish, no more than words picked as matter of artificial taste in entry level translations done by humans.