Tom Hughes-3 wrote > On 17/10/12 22:17, Andy Allan wrote: > >> On 16 October 2012 00:17, Tom Hughes <
> tom@ > > wrote: >> >>> The way it works is this - you don't worry about translations as such at >>> all. You just make sure strings are translatable and we commit that and >>> then >>> the translators get to work. Yes, when something new launches it will >>> take a >>> while to get translated, but that is something we live with as a >>> volunteer >>> project and it had worked perfectly well up to now. >> >> It hasn't worked perfectly well up to now - as you've just described. >> We should be able to make changes on a staging branch, get >> translations sorted, and push live with as little untranslated >> material as possible. The current situation, where it's impossible to >> get translations ahead of merging into master, along with translation >> updates being now-and-then rather than automatically fed back withing >> a few tens of minutes, is less than ideal. > > Well yes I'm sure it would be absolutely lovely if we could do all that > but I don't see it as realistic in a volunteer open source project. I would think that with relatively minor effort, the situation can be greatly improved. It obviously won't be perfect, but better than what he have now. Tom Hughes-3 wrote > Even if we had the technology you propose, how long do you think we > should wait in the hope that translations arrived before pushing > something like? Without paid translators we have no way of ensuring > timely translations even if we do all the things you suggest... You don't have to ensure or guarantee that all strings are available in all languages, but it would be nice if for the main languages you typically don't see major breakages in l10n. Translatewiki works pretty well as a translation platform and has a pretty decent rate of translating (at least for some languages) From what I have seen from trying to help translate osm to German (which is the only language other than English I can contribute to), all strings are usually translated in a pretty short time once they hit Translatewiki. That is probably true for the major other languages used as well. So if you publish string changes in a staging branch for up to a couple of days or a week, I suspect most strings are translated by the time they hit production. That probably won't work for languages like Esperanto, Volapueck or a regional dialect like Pälzisch, but it should work for the major languages like Russian, Spanish, Japanese or German, covering the vast majority of OSMs users. Tom Hughes-3 wrote > I would certainly have no objection to a platform that would be able to > feed things back more quickly, though 10 minutes might be rather painful > unless we move away from keeping the translations in git. > > Having to push everything through a lengthy period on a staging branch > would be a major change in our modus operandi though, both in terms of > increasing the time it took for changes to make it to production and in > terms of significantly complicating my life. I think a system like the following could potentially work: The current git branch will be pushed to just as today, but becomes a "staging" branch. Translatewiki pulls and pushes to this branch. Ideally a pull to Translate wiki happens automatically on a push to en.yml to make sure that any new strings hit Translatewiki as soon as possible, but a daily pull would probably be fine as well. A new beta.openstreetmap.org is introduced that runs off of the "staging" branch and has equal write access to the main database. I.e. is fully functional for anyone who wants to use this as their main openstreetmap website. www.openstreetmap.org is then on e.g. a 7 day delay off of the staging branch. This gives people time to test any changes to reduce the chances for accidental breakage, as well as give translators time to translate things. Although it would change the current model, I suspect it wouldn't add too much more hassle to your workflow and thus possibly be workable. The pull from "staging" to "production" (if not automatic) could probably also be done by other members of the OWG to make sure that the impact on you would be minimal. Just some thoughts, Kai -- View this message in context: http://gis.19327.n5.nabble.com/Notes-OSM-improvements-BoF-at-SOTM-PDX-tp5730849p5731338.html Sent from the Developer Discussion mailing list archive at Nabble.com. _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
