OpenHistoricalMap (OHM) translations needing a review
Note that this does not necessarily affect all languages: if they were copied verbatim by some bot (from resources translated for OSM), they need updates to match with OHM, which is still hosted by the OSM Foundation, but operated under different rules (and with a new OHM Foundation which will regulate it but which is still informal), and uses separate licences, separate user registration and contributor terms.
As well there are things to develop to better track the various licences used in the data (because there's no more any single licence, each object tracks its own licence, and it will not be easy to work with it with existing OSM editors (and data import tools, or QA tools): we don't even have an easy way to modify data if users operate under different licences, so a licence filter will be needed everywhere, notably in editors, and in data extraction and export tools). Because of that, new contributors may not easily track what is allowed or not, and working with different licences and timeframes will be very impractical, either damaging the geometries needed for other timeframes, or not allowing to close them corerctly with a complete geoetry, if subobjects needed are using an compatible set of licences (that existing editors and tools do not currently allow to check: merging nodes at the same or similar position for example will remain a problem).
For example, I carefully took that into account in French by not confusing the two projects.
Anyway the OHM project is still starting and still not really in production: there are lot of works to adapt it, including updating client tools, and probably define new attributes and methodologies to work with historical data and allow the map renderers to take that info into account (e.g. to "play" changes over a period of time), and some of these are unstable and need to be fixed: the OHM project will update these messages when necessary, so they will be marked "fuzzy" when they'll do. I think it is more like an alpha stage, just existing for now to demonstrate its feasibility. It's still not tuned for large-scale production and users will need to be trained to work correctly with the new rules (notably with licences).
Major issues when objects are linked together (e.g. ways defined in a given licence, but reusing shared nodes created with another; same thing relations, including for geometric areas using sets of ways that may not use all the same licences). It will also not be easy to track the validity in time. Editors will need to be smart to allow selecting or not some node that was defined for a specific date or period (in addition to the problem caused by the multiplicity of licences).
Things would be easier if instead of that, the legacy OSM data was using the general concept of "data layers" that would group objects belonging to the same timeframe, and the same (or compatible) licences, just like what is done in other GIS systems. But for now that extension does not exist and the existing "OSM v0.6" schema seems to be insufficient: it will need extensions to make those data easily reusable and editable, exportable and reusable. Lots of technical things will have to be discussed, and tested. So that project will necessarily deeply evolve with its own needs (but may be some of its extensions may become usable as well in OSM).
So I still consider OHM to be in alpha stage, a trial for demonstration and exhibiting the problems on limited areas for tests, before it can be used more globally. For now, other GIS solutions are preferable, just because they work on distinguishable layers of data and don't need to merge anything with unrelated datasets managed separately with their own policies.
And may be all OHM contributions should be made in layers, and merging layers (for reusing data, or faster rendering) should be performed selectively on the client side, not in the OHM database itself (in that case, nothing will prohibit OHM clients to use the OSM database just as one of the layers). But if OHM develops a new extended model, it could be useful as well for OSM itself (even if it focuses on just rendering the most recent data, but still does not accept planned data related to the future, such as construction areas) and could simplify the work on OSM for import bots (the actual merging could be made by OSM-trusted bots, after checking dates and compatiblity of licences), and the work in cooperating teams (each contributor would have his own layer, merged in the main layer only by linking to layered data), including for newcomers (who could also "try" their own layers, giving their owrk to other trusted users to fix it before it can be merged)
All this has nothing to do with translation. This technical work should be worked and discussed with OSM and OHM, and see later if these two projects can merge their efforts with a shared (layered) database using a new data model (but still offering an API compatible with v0.6 to give access to the "merged" layer (containing only data compatible with ODbL and with the correct current timeframe), which would no longer be directly editable directly but infered/generated by processing). It would also greatly facilitate the fight against abuses in OSM (copyvios, destruction/randomization, spammed contents) or unobvious errors made by contributors themselves (which are hard and costly to locate and fix after submission, even if they made their best efforts).
Note: I transformed your long list of messages first into a vertical list, but then into a bulleted list, showing links to messages: the links go to the translated versions, according to the current user's language, or the language you specify by looking at this page with "?uselang=code" added to the URL of the current page).
That list does not test if these translated message exist (because we are limited to 100 "#ifexist:" tests on this wiki) so these links may go to a wiki editor if these translations do not exist; it also does not show their textual content.
This makes the list more compact in the support page.
Thanks for all the information! I would love to draw our heroic period in history 'Magna Frisia' on the map. We even learned the English to talk proper English in those days. Note to self: look up if that is true ;-)