migo315

Oder bei den Übersetzungen machen wir nen mittel Ding. Ich hatte schon mal hier in diesem Thread über den Unterscheid der "statischen" und "dynamischen" Übersetzungen geredet. Statische Übersetzungen machen mit Abstand das meiste im Projekt aus. Jeder Text ist fast eine statische Übersetzung, die wieder verwendet wird und unter https://crowdin.com/project/coastercloud gepflegt werden kann. Statische Übersetzungen sind für mich per se OK. Ich übersetze etwas einmal und kann es immer wieder verwenden. Auch sogut wie alle Attribute sind statische Übersetzungen.

Die dynamischen Übersetzungen sind wirklich "Freitexte". Also welche, die konkret individuell nur auf den Park / Attraktion geschrieben werden. Davon gibt es nicht viele. Und aktuell kann man diese auch nicht in verschiedenen Sprachen hinterlegen. Jeweils für Parks und Attraktionen sind es "nur" folgende Bereiche:

- Beschreibung (die Kurzbeschreibung)
- Thema (ein Feld in dem man das Thema beschreibt wie "Western Stadt")
- Besonderheiten (die Sammlung der Besonderheiten wie "Ältester Coaster Deutschlands")
- Historie (Bei speziellen Events wie "2015 abgebrannt")

Ggfs. nehmen wir dann erstmal nur die dynamischen raus. Also komplett und beschränken die Pflege auf alles, was nicht lokalisiert werden muss oder über statische Übersetzungen funktioniert. Würde in diesem konkreten Fall bedeuten, dass die 4 Felder oben wegfallen würden. Wobei man Historie zumindest teilweise auch mit statischen Übersetzungen hinbekommt (sowas wie Eröffnet, Geschlossen etc).

Bei allen was ich hier offen diskutiere  stellt sich mir immer der Gedanke: Was bringt das Projekt weiter? Und aktuell habe ich das Gefühl, dass das Thema dynamische lokalisierung mich sehr ausbremst. Würde ein (temporär) wegfallen solcher Felder ggfs. den Fokus auf die restlichen Felder erhöhen? Oder nimmt es zuviel Attraktivität raus? Wäre es vll besser erstmal weniger Anzubieten aber dafür stärker auf die Pflege zu gehen? Das sind so Fragen, die ich mir aktuell Stelle.

Und noch eine zweite Interessante Diskussion: Das Projekt hat auf deutsch angefangen. Nun unterstützt es deutsch und englisch. Wobei es mehrere Felder gibt die noch nicht übersetzt werden können (zb. Beschreibung).

Ich spiele immer mal wieder mit dem Gedanken nur auf englisch zu gehen. Also alle Seiten auf englisch, alle Daten auf englisch. Das würde das komplexe Thema der lokalisierung eliminieren. Deutsche Apps etc. müsste dann ggfs. selber übersetzen. Sofern die überhaupt Texte übernehmen. Den Daten wie Sicherheitbestimmungen, Wartezeiten und technische Daten wie Höhe oder Länge sind ja quasi ohne lokalisierung nutzbar. Ich kann nicht einschätzen, inwieweit dies potenzielle Entwickler abschreckt. Aber mir würde das zumindest die Arbeit erleichtern. Und es käme zu keinen inkonsistenten Daten (weil zb. auf deutsch mehr gepflegt ist als auf englisch).

Was meint ihr?

Eine Doku würde ich natürlich machen. Quasi sowie in http://graphql.org/swapi-graphql (klick mal oben rechts auf "Docs", dann kann man sich durch klicken). Meinst du sowas?

Jetzt nochmal über die API nachzudenken ist schon irgendwie doof. Aber andererseits empfinde ich es echt schwer eine API zu designen, die jeden hilft und auch noch in 2 Jahren keine "technischen Schulden" hinterlässt.

Ich glaub ich werde die aktuelle API nochmal als "experimantal" deklarieren und festmachen, dass ab dem 11. November die API zu "Stable" überläuft. Dann können wir noch ein  paar Wochen austesten und probieren, bevor wir uns festlegen. Jetzt, solang noch kaum jemand die API nutzt, können wir sowas ja noch machen. In nem Jahr wird dies wohl schwieriger.

@RooStar @Tommy

In den letzten Tagen bin ich echt am Design der API noch am grübbeln. Eigentlich steht dies ja bereits fest. Aber ich merke selber oft, dass der Endpunkt nicht immer alle Informationen so zurück gibt, wie ich es manchmal brauche. Ergo: Ich muss zwei Calls machen.

Seit Tagen mache ich mir dazu Gedanken, wie es ich verbessern möchte. Eigentlich möchte ich jede Ressource (Park, Attraktion) einen eigenen Endpunkt geben (so wie es jetzt ungefähr ist). Mehrere Calls zu machen wenn ich aber übergreifend Informationen benötige ich auch gerade optimal. Hinzukommt, dass man oft auch gar nicht alle Informationen aus der Response benötigt. Beispiel: Will ich nur die Park Namen für eine Liste, erhält man aktuell auch alle Eigenschaften, Historie etc von allen Parks, was die Response recht fett macht.

Nun evaluiere ich GraphQL anstatt der REST API zu nutzen. Habt ihr damit schon Erfahrungen gemacht? Das ermöglicht den Entwickler, alle Informationen die er benötigt selber ausszusuchen. Der Entwickler erhält also alles was er will - ohne "Datenmüll". Hier ein cooles Beispiel für die Star Wars API: http://graphql.org/swapi-graphql

Was meint ihr?

Wenn ich zum Beispiel alle Star Wars Filme zurück erhalten möchte inkl. der Namen aller Planeten die in dem Film spielen, sehe die Request so aus:

Zitat

{
  allFilms {
    films {
      title,
      director
      planetConnection {
        planets {
          name,
        }
      }
    }
  }
}

In der REST API wäre Planten und Filme jeweils ein eigener Endpunkt, was zu doppelt Calls und Datenmüll führen würde.

vor 2 Minuten schrieb Kleator:

Naja hier können doch sehr gut die eingepflegten Daten von deiner Seite zugrunde gelegt und ausgewertet werden.

Darauf wollte ich ja hinaus.

So eine App gibt es noch nicht, kann aber jetzt entwickelt werden danke der Daten von coaster.cloud.

Ideen habe ich immer viele. Ein Kollege von mir will die Wartezeitdaten nutzen und so analysieren, dass für die nächste Tage geschätzt wird wie voll es wird.

Eine App die ich als Familienvater vermisse: Freizeitpark Planner.

Eine App (oder Seite), wo ich die Größe und Alter der Familie eingeben und der Planner zeigt mir, welche Parks sich für meine Familie aktuell am meisten lohnt. Also quasi "Im Phantasialand können wir ingessamt als Familie 20 Attraktionen fahren, im Movie Park nur 10 weil der kleinste nur 80 cm groß ist".

Am 14.10.2019 um 15:34 schrieb Kleator:

Ich versuch mich weiterhin daran alle möglichen Parks einzutragen (Folgende hab ich schon: Link - Spreadsheeet). Fehlt nur die Zeit momentan.

Ich werde die nächsten Tage PortAventura, Movie World Madrid und Parque de Attraciones samt Attraktionen pflegen. Paar Kollegen haben von den Attraktionen Fotos gemacht, welche die dann hochladen.

vor 14 Stunden schrieb RooStar:

Es wird auch nicht jeder Freizeitparkbesucher meine App nutzen, auch wenn ich es gerne hätte.

Tatsächlich ist der Markt übersättigt was Webseiten, Blogs und Apps für Freizeitparks angeht. Und das in einem Markt, der die meisten ja eben nicht interessiert. Klar, viele Leute gehen in den Freizeitparks aber viele greifen dabei nicht auf inoffizielle Seiten und Apps zurück. Eine Tatsache, mit der ich mich anfangs auch erst sehr schwer anfreunden konnte.

Am 11.10.2019 um 13:19 schrieb RooStar:

Attraktionen

Shows

Restaurants/Snacks

Souveniers/Shops/Informationen

 

Hotels und Eingänge sind geplant.

 

Parkplätze sollen über eine "Wo ist mein Auto?"-Funktion hinzu kommen...

 

Also am Ende die gesamte Bandbreite...

 

Testweise ist auch ein RideCount implementiert, gefahrene Attraktionen (Blaue Marker) erhalten dann ein Sternchen...

coaster.cloud kennt bisher nur Attraktionen und Parks. In Planung sind noch "Point of Interest" welches quasi Shops, Läden und co abdeckt und auch die Hotels. Ehrlicherweise wird dies aber wohl noch ein paar Wochen oder im worst case auch Monate dauern.

Btw vll für dich interessant: Navigation innerhalb des Parks. Du wählst eine Attraktion aus und die App zeigt dir den Weg wie du laufen musst um am Eingang zu kommen. Ich habe keine Ahnung, wieviele das nutzen würden. Ich selber würde es vermutlich nicht nutzen. Aber ich bekomm immer wieder mit, was manch einer überfordert ist Attraktion  XYZ zu finden.

Die nächsten Tage werden auf coaster.cloud eher unspektakulär. Bin viel am Hintergrund am optimieren. Das Resultat wird eine noch flexiblere API.

vor 2 Stunden schrieb RooStar:

Dann lass mir doch mal deine Email Adresse zu kommen, dann schicke ich dir meine ganzen XML Daten zu! 

Schicke ich dir per PN

vor 2 Stunden schrieb RooStar:

Wenn du die Post Methoden fertig hast, würde ich mich sehr freuen wenn ich ein eigenes Pflegeprogramm zu dem Projekt zusteuern könnte. Denn wenn ich was nutze will ich auch was zurück geben.

Habe da auch bereits ein Konzept im Kopf wie ich das mit interaktiven Karten umsetzen könnte.

Klar - würde mich freuen

vor 2 Stunden schrieb RooStar:

Der Name meiner App "Coaster Guide" war nämlich von Anfang an so geplant, dass jeder Daten hinzu steuern kann.

Anders bekommt man ja auch soviele Daten gar nicht aktualisiert. Man ist auf die Community angewiesen.

Beim Phantasialand hast du noch mehr gepflegt als nur Attraktionen - oder? Sieht zumindest auf dem Bild so aus. Was pflegst du denn alles? Buden? Hotels? ..?

Wie von @to b erwähnt, steht eigentlich auf Seite 1 alles. Nur beachten, dass das Projekt von "coaster-platform.org" auf "coaster.cloud" umbenannt wurde.

Hier nochmal in kurz:

vor 49 Minuten schrieb RooStar:

Verstehe ich das richtig das die Coaster Cloud Datenbank von dir/euch ist? 

Jap.

vor 49 Minuten schrieb RooStar:

Seit wann besteht das Projekt denn? 

Entwicklung begonn frühjahr 2018. Dezember 2018 ging ich damit an diese Community ... quasi eine Art "Soft Opening" um Feedback zu erhalten. Dafür ist ja auch dieser Thread.

vor 52 Minuten schrieb RooStar:

Hätte nämlich ggf. Daten von einigen Parks im Angebot die ich dann zur Verfügung stellen würde.. 

Wäre sehr nice

vor 53 Minuten schrieb RooStar:

Mit der neuen Version meiner App soll zusätzlich ein Pflegeprogramm für Windoof entstehen über das ich für mein Projekt dann in Zukunft noch mehr Daten einpflegen könnte...

Aktuell kann die API nur Daten abfragen. Aber tatsächlich wird es demnächst (= ein paar Wochen) auch die Möglichkeit geben, Daten über die API einzupflegen.

vor 2 Stunden schrieb RooStar:

Mit anderen Worten ich kann die Datenbank kostenlos für meine Projekte (auch kommerziell) nutzen und als Gegenleistung Daten einpflegen?

Die Daten stehen unter der Creative Commons Lizenz  - eine Lizenz die auch Wikipedia verwendet. Bedeutet: Du kannst die Daten kostenlos für beliebige Zwecke nutzen - auch kommerziell. Eine konkrete Gegenleistung wird nicht erwartet - außer eben die Lizenzbedingngen einzuhalten. Die sind aber leichte Kost. Für die Nutzung der API ist auch keine Registrierung notwendig. Du kannst diese anonym nutzen.

Trotzdem freuen wir uns aber natürlich, wenn Leute Parks oder Attraktion pflegen. Das Ziel dahinter ist, dass alle was davon haben und jeder ne coole App / Blog o.ä. bauen kann ohne sich zum X-ten mal die Daten zusammen zu suchen.

Das ist aber alles gerade Off topic. Wir sollten das wenn hier weiter diskutieren: https://www.phantafriends.de/topic/3530-coaster-platform/page/6/

Ich habe kein Android Handy oder Uhr. Nur iPhone bzw. Apple Watch. Sorry

Meine letzten Arbeiten mit Android sind auch schon verdammt lang her. Vor dem iPhone hatte ich sogar noch Windows Phones.

vor 20 Stunden schrieb RooStar:

Meine App hat zwar keine Wartezeiten und ist auch nicht aktuell, dafür sind aber bereits viele Parks eingepflegt. Momentan läuft die App auch komplett offline und hat noch keine API dahinter liegen. Das ist was, was ich noch in Zukunft vorhabe. 

Bevor du dir jetzt deine eigene API baust: Nutze coaster.cloud. Genau dafür ist das Projekt da. Du kannst Park-, Attraktionsdaten sowie aktuelle Wartezeiten über die API einfach abfragen: https://api.coaster.cloud/

vor einer Stunde schrieb Betatester:

Wäre eine Umsetzung für Samsung Wearables(Galaxy Watch,Gear S3,..) welche auf Tizen OS laufen auch denkbar ?

Vom Prinzip her schon ...

vor 48 Minuten schrieb RooStar:

Habe mir ein mal das IDK für Tizen angeschaut, danach habe ich meinen PC runter gefahren und mir gedacht "Nein danke!"

Da ist es definitiv Einfacher für das Wear OS zu programmieren...

... muss hier aber RooStar zustimmen, dass das Tizen SDK jetzt echt uncool aussah. Zumindest auf dem ersten Blick. Ich schau mir das die Tage mal genauer an. Zwangsläufig muss ja auch nicht unbedingt alles von mir Entwickelt werden. Von Vorteil wäre, wenn derjenige der die App für ein System entwickelt diese auch selber testen kann (weil er / sie entsprechend so eine Uhr hat).

vor 6 Stunden schrieb RooStar:

Und woher beziehst du die Daten? Die API für die offiziellen Wartezeiten z.B. vom Phantasialand dürften ja verschlüsselt sein...

Naja, dass es Wege gibt an Daten zu kommen ist ja ein offenes geheimnis. Seiten wie https://www.looopings.nl/wachten/phantasialand machen es ja bereits seit langem vor. Auf Github gibt es sogar kostenlose Libraries / Programme dafür. Für diese Apple Watch App beziehe ich die Daten aus https://coaster.cloud. coaster.cloud holt sich nicht aktiv die Daten sondern erhält diese von dritten.

vor 4 Stunden schrieb Prada79:

Hättest du die Kohle bei ca. 1€ für die App relativ schnell wieder drin? Es werden sich doch sicher 100-200 Käufer finden lassen, zumal das ja auch nicht auf einen Park begrenzt zu sein scheint. 

Für alle Parks, bei denen man LIVE Daten bekommt. 100-200 Benutzer bekommt man sicherlich nach einer Zeit. Aber 100 - 200 Nutzer die nen Euro bezahlen - puhh. Da bin ich mir nicht sicher. Den großteil ist selbst ein Euro für eine App zu teuer (und das obwohl man sich eine >300 € Uhr leistet). Aber selbst wenn: Ich habe kein Interesse dafür im Shop Geld zu nehmen. Sobald ich dies mache, ist dies kommerziell. Und Kommerziell bedeutet mehr Aufwand und mehr Risiken. Daran habe ich kein Interesse. Btw: Auch Werbung ist keine Option. Ebenfalls kommerziell und bin auch kein großer Fan davon.

vor 5 Stunden schrieb Prada79:

Ich fänds ganz witzig, sofern die Zeiten auch wirklich so aktuell wie möglich sind

Die Daten sind aktuell. Alles andere wäre ja auch Witzlos. Kannst du hier einfach nachprüfen: https://coaster.cloud/de/waiting-times

vor 5 Stunden schrieb Prada79:

Das Handy-Rausholen nervt ein bisschen, weil ich halt ständig checke.

Jap - deswegen fand ich die Idee mit der Watch ebenfalls mega!

@all

Ich werde mal nen MoneyPool bei PayPal bereitstellen. Vielleicht kommt ja etwas zusammen. Wenn ja cool - wenn nein, auch nicht schlimm. Solang kann ich ja dann an einer App für Android Uhren und Fitbit bauen.

vor 3 Stunden schrieb TOTNHFan:

Ich kann mein Geld sinvoller aus dem Fenster werfen als für den angebissenen Apfel... 

Die Apple Produkte sind überteuert. Gebe ich dir vollkommen recht. Vom Geld abgesehen, bin ich aber mit dem Produkten recht zufrieden. Zur App: Auch für Android Wearables und Fitbit wäre dies machbar (und wurde schon bei mir angefragt).

vor 3 Stunden schrieb Prada79:

: Hö? Wie das?

Selbst entwickelt. Die App checkt im welchen Park du bist (GPS) und zeigt dir (sofern vorhanden) die aktuelle Wartezeiten an. Idee ist nicht von mir - habs aber mal testweise umgesetzt. Plan wäre sowohl für Apple Watch, Android Wearables und Fitbit rauszubringen. Für Apple Watch ist die App quasi sogar fertig - aktuell streube ich mich aber noch  die 99$ zu zahlen um die App zu veröffentlichen.

Gibt es hier eigentlich Apple Watch nutzer?

Jap - es wird nicht alles aufgelistet. Eine erste Version habe ich soeben veräffentlicht. Rechts bei der Filterung kann man sowohl bei Parks als auch bei Attraktionen nun nach bestimmten "Tags" filtern:

"Technische Daten fehlen" wird angezeigt, wenn weniger als 2 Attribute gepflegt sind. "Adresse fehlt" wenn auch nur ein Teil der Adresse fehlt (bsp. Straße oder Land). "Koordinaten fehlen" wird angezeigt wenn eines der beiden Koordindaten fehlt (Breiten- / Längengrad). Bei Attraktionen gibt es noch "Sicherheitsbestimmungen fehlen" - das wird angezeigt wenn weder Alter noch Größe für "Ohne Begleitung" gepflegt ist. Eines von beides sollte ja prinzipiell immer gefüllt werden können. Rest sollte klar sein.

Hey,

es gibt eine neue Freaky Funktion: Anmelden

Tatsächlich habe ich erst vorgestern gemerkt, dass seit der Einführung der englischen Sprache der Login nicht mehr funktioniert hat. Das ist mir leider nicht aufgefallen, weil ich mich selber zuletzt nicht angemeldet habe. Hätte ja ruhig mal einer melden können

Jetzt funktioniert dies auf jeden Fall wieder!

Mal von diesem fetten Bug abgesehen, ist nicht viel passiert. Ich habe weiter an den Übersetzungen gearbeitet (wer fit in englisch ist kann gerne unter https://crwd.in/coastercloud gegenlesen und korrigieren) und paar Bugs behoben. Die größten Änderung habe ich am Alexa Skill gemacht. Dieser kann nun auch die Sicherheitesbestimmungen nennen: "Alexa, frage Park Guide ab wann man Taron fahren darf". Mehr dazu auf https://www.amazon.de/migo-Park-Guide/dp/B07WRGM736

In den nächsten Tagen möchte ich die Funktionen zur Pflege weiter optimieren. Unter anderem möchte ich für Parks und Attraktionen einen Pflegestatus einführen. Dieser ermittelt dann automatisch wo noch was gepflegt werden muss. Anhand einer Liste kann man dann sich zb. Parks / Attraktionen anzeigen lassen, wo noch Bilder oder Sicherheitsbestimmungen fehlen.

Am 16.9.2019 um 18:25 schrieb Winjas007:

Also ich würde sagen der Sonntag ist deutlich ruhiger als der Samstag

Die beobachtung mach ich in anderen Parks auch. Obwohl ich eigentlich immer den Sonntag voller erwarte.

Falls hier jemand ist mit guten Englisch Kentnissen ... ich übersetze aktuell das Projekt. Fänd cool wenn sich der ein oder andere, der die Sprache ein wenig beherrscht, sich mal meine Übersetzungen ansehen und ggfs. Verbesserungsvorschläge nennen kann.

Liegt alles offen auf CrowdIn: https://crwd.in/coastercloud

Am 8.9.2019 um 15:38 schrieb Krähenfeder:

“Dann Talocan. Die Taron ist so schnell, da merkt man den Looping gar nicht“

Meine Erfahrung ist auch, dass für viele "normalos" der Begriff Looping sehr dehnbar ist. Eine Kurve mit seitlicher Lage reicht da oft schon aus

Bisher das beste was ich mitbekommen habe: Van Helsings Factory hat nen Looping.

Hey Leute,

ein paar News: Mittlerweile gibt es immer mehr Leute die etwas mit der API probieren und etwas damit entwickeln. Bisher war die API ja immer in einem "Entwicklungsstatus" - bedeutet nach neuen Feedback von Entwickeln wie auch beispielsweise von @Tommy sowie meinen eigenen Erfahrungen mit der API, habe ich Änderungen vorgenommen die teilweise ein Breaking Change verursacht haben. Bei einem Breaking Change funktioniert die API nicht mehr wie vorher und der Entwickler muss seine APP / Blog / Webseite entsprechend anpassen. Das ist normal in der Anfangphase - aber wie erwähnt interessieren sich immer mehr Leute dafür, die API zu nutzen.

Daher wurde gestern Abend nun die erste "stable" Version der API veröffentlich. Die nun dokumentierten Endpunkte der API werden zu keinen Breaking Change mehr führen. Auch die URL o.ä. wird sich nicht mehr ändern. Der Entwickler kann also sicher sein, dass die Aufrufe zur API auch noch in 5 Jahren funktionieren wie diese es jetzt tun.

Die API findet sich nun unter https://api.coaster.cloud/

Die Dokumentation der API wurde ebenfalls nun stark verbessert.

Ansonsten habe ich selber weiter mit der Pflege von Parks beschäftigt. Bobbejaanland, Europa Park, Walibi Belgien und Walibi Holland sind nun gepflegt. Letzten 4 auch mit aktuellen Wartezeiten. Lediglich Bilder, paar technische Daten und Sicherheitsbestimmungen fehlen. Letzteres werde ich die Tage nachholen. Bilder habe ich keine. Wer also für die Parks Bilder hat, wäre ich sehr denkbar wenn ein paar den Weg zur coaster.cloud finden würden

Am 26.8.2019 um 08:58 schrieb jen_f13:

Ich finde die Idee gut! Es gibt nunmal auch mehr Parks außerhalb des deutchsprachigen Raums wo man Infos zu Thema, Historie etc sowieso eher auf Englisch findet.

Jap - genau!

Am 27.8.2019 um 13:45 schrieb Kleator:

Da ich schon einiges mit DeepL rum experementiert habe, weiß ich auch, dass das meiste (also auf jedenfall besser als google!) richtig und gramatikalisch korrekt ins Englische übersetzt wird, bzw. auch anders rum ins Deutsche.

Kenn das ja durch dich. Hab mich damit ein wenig beschäftigt und finde die Übersetzungen auch in Ordnung. Und da die mittlerweile ihre Preise angepasst haben, wäre der Zugriff per API auch nun bezahlbar.

Am 27.8.2019 um 13:45 schrieb Kleator:

Auch zu erwähnen ist die Masse an Attraktionen die du und andere hinzugefügt habt! Ich werde mal schauen, dass ich meine Parkliste weiter abarbeite und den Reset weiter hinzufüge...

Jo danke! Ich selber habe mir auch vorgenommen mindestens ein Park pro Woche einzupflegen um den Datenbestand in den nächsten Wochen massiv zu erhöhen. Heute war der Bobbejaanland ( https://coaster.cloud/parks/bobbejaanland/attractions ) dran. Leider habe ich kaum Bilder in den Jahren gesammelt.

Dito - bei mir läufts auch schnell.

Ich brauch euch mal fürs Brainstorming. Eines meiner Ziele ist es, auch zeitnah in anderen Sprachen Live zu gehen. Primär natürlich in Englisch. Damit soll die Reichweite des Projekts stark vergrößert werden.

Offen bleibt das Thema der Übersetzung. Dabei muss man zwischen statischen Texten und dynamischen Unterscheiden. Statische Texte pflegen ich in einer Sprachdatei. Diese zu übersetzen ist kein Problem - dies mach ich selber. Quasi fast alles im Projekt sind statische Texte. Von der Startseite über das Impressum als auch die Feldbezeichnungen und Drop Down Inhalten. Also alles wo man nur auswählt, klickt o.ä. sind statische Texte.

Interessanter sind die dynamischen Texte. Das sind die Inhalte, die man nicht auswählen kann sondern der Benutzer aktiv schreibt. Davon gibt es nur wenige Felder: Kurzbeschreibung, Inhalt des Feldes "Thema", Inhalt in der Historie und Inhalt der "Features" Felder bei Parks und Attraktionen. Diese müssen ebenfalls übersetzt werden - dies wird aber der Benutzer wohl nicht für jede Sprache machen. Es muss also automatisch passieren. Ein Mix aus verschiedenen Sprache und hin und her übersetzen halte ich aber für nicht so gut.

Daher meine noch recht junge und unverbindliche Idee: Die Pflege aller Daten passiert ausschließlich auf Englisch. Also wird die Beschreibung beispielweise immer in Englisch geschrieben. Und dank einer API wie DeepL (Dank an  @Kleator für den Tipp nochmal) wird von Englisch in den verschiedenen Sprachen (Deutsch, Französisch, Niederländisch, Spanisch) übersetzt. Englisch eignet sich dafür, weil sich Englisch am sichersten in allen anderen Sprachen übersetzen lässt und Englisch de facto eh die Weltsprache ist.

Was meint ihr dazu? Wäre es für euch vorstellbar? Ich mein auf anderen Plattformen wie rcdb pflegt man imho ja auch auf Englisch. Oder wäre es für euch ein großer Hindernis Daten zu pflegen? Es gibt wohl gemerkt nur um die Pflege. Der normale Besucher erhält dann alles schön übersetzt.

Mein letzter Beitrag ist schon über 2 Monate alt. Aber lasst euch nicht täuschen - während dessen habe ich immer wieder weiter dran gearbeitet.

Hier mal die größten Änderungen seit meinem letzten Beitrag:

1. Umbenennung zu coaster.cloud

Da im meinem Umfeld immer wieder Leute Probleme mit "coaster-platform.org" hatten und ich den Namen eh nie sexy fand, gab es nun eine Umbenennung. Das Projekt wird nun unter den Namen "coaster.cloud" geführt und hat die gleichnamige URL https://coaster.cloud. Um ein freshes Logo kümmer ich mich noch.

2. Wartezeiten hinzugekommen

Hier gibt es direkt zwei neue API Schnittstellen: Einmal um Wartezeiten abzufragen und einmal um Wartezeiten einzutragen. Bedeutet, auf coaster.cloud kann man nun Wartezeiten abfragen. Die Zeiten selber sollen dabei wieder aus der Community kommen. Dafür gibt es nun den ersten "schreibenden" API Endpunkt um über die API Sachen zu speichern. Während das Abfragen wie üblich jeder kann, muss man für das Eintragen einen Account auf coaster.cloud haben. Dazu demnächst mehr Details.

Hier, wer mal schauen möchte: https://coaster.cloud/queue-times

3. "Alexa, frage Park Guide wie schnell ist Taron?

Eigentlich mehr Spielzeug als Sinnvoll: Der Alexa Skill "Park Guide". Dieser entstand aus der Idee einfach mal die API zu nutzen und zu zeigen, was alles möglich ist. Den der Skill nutzt nur die Informationen und die jeder dank coaster.cloud nutzen kann. Langfristig werde ich den Alexa Skill an jemanden, der Lust hat dies weiter zu pflegen, abgeben. Bis dahin werde ich ab und zu Alexa ein paar Freizeitpark Informationen beibringen

Mehr Infos unter https://coaster.cloud/alexa

4. Pflichtfelder entfernt / schnellere Eintragung

Wenn man Attraktionen erstellt hat wurden ein paar technische Details vorausgewählt. Dies entfällt nun. Der Sinn dahinter war, dass die simplen Ja / Nein Felder eigentlich jeder wissen müsste. Als ich selber aber zuletzt ein paar Attraktionen gepflegt habe, konnte ich diese nicht "beantworten". Ich musste also raten - das ist ja nicht der Sinn einer Datenbank. Daher gibt es keine Vorauswahl mehr bei Neuanlagen von Attraktionen. Außerdem wurde ein zweiter Speicher Button hinzugefügt, womit man nach dem Speichern direkt eine weitere Attraktion erstellen kann.

5. Neue Felder

Es gibt zwei neue Felder. Eines um "Umgangssprachliche" Namen zu speichern. Beispiel: Man sagt ja meist nicht "Das verrückte Hotel Tartüff", was der offizielle Name ist sondern meist eher nur "Hotel Tartüff". Oder statt "Movie Park Germany" sagt man ja meist nur "Movie Park". Um solche Einträge geht es. Des Weiteren wurde ein Feld für das Handling von Rucksäcken hinzugeügt (darf Rucksack mitgenommen werden auf Attraktion oder muss es in einem Korb o.ä.).

6. Historie überarbeitet

Das lag mir lange echt im Magen. Ich war mit der Historie und dem "Eröffnet" / "Geschlossen" Felder nicht zufrieden. Grund dafür ist zb. "Crazy Bats". Eröffnet wurde es 1988, aber jetzt quasi "Neueröffnet". Welches Datum speicher ich nun im "Eröffnet" Feld? 1988 wäre richtig, aber 2019 wäre wichtig um es bei Neuheiten zu sehen. Lange wusste ich nicht, wie ich es handeln soll. Nun ist aber eine Lösung gefunden: Die Felder für "Eröffnung" und "Geschlossen" gibt es nicht mehr. Sowas wird nun in der Historie gespeichert. Dafür kann man in der Historie nun den Typ auswählen.  Das sorgt dann für eine saubere Historie und einen sauberen Datenstand (siehe Screenshot). Die Historie wird nun auch in einem eigenen Tab dargestellt, da diese je nach Park / Attraktion sehr groß sein kann.

7. Suchengine ausgetauscht

Den austausch der Suchengine wird quasi niemanden interessieren. War aber der heftigste Punkt. Dafür habe ich gut zwei Wochen gebraucht. Das hat sich aber gelohnt, da wir nun viel bessere Abfragen durchführen können. Zudem ist das Sortieren nun möglich. Diese Anpassung passiert also eher im Hintergrund - ermöglicht aber viele neue Sachen.

Das waren so die für euch relevantesten Punkte. Hier nochmal eine kleine Liste aller Anpassungen:

Zitat

- Suchengine komplett ausgetauscht (ermöglich bessere Filter und Sortierungen)
- Die Filterung nach Größe / Alter wurde verbessert
- API für Aktionen um Wartezeiten Abzufragen und zu speichern ergänzt
- RabbitMQ mit Postgres ersetzt
- Pflichtfelder bei „Technischen Daten“ komplett entfernt
- Speichermöglichkeit hinzugefügt um direkt neue Attraktionen zu erstellen
- Sortierung für Parks und Attraktionen werden nun von der API unterstützt
- Parks und Attraktionen werden nur alphabetisch sortiert / bei der Suche nach Relevanz sortiert
- Projekt von „Coaster Platform“ nach „coaster.cloud“ umbenannt (Domain ebenfalls getauscht)
- Wartezeiten von Parks werden nun angezeigt
- Einige Performance Optimierungen
- Neues Feld für „Umgangssprachliche Namen“ für Parks und Attraktionen ergänzt
- Neues Feld für Handling der Rucksäcke bei Attraktionen ergänzt
- Alexa Skill „Park Guide“ erstellt
- Einiges an unnötigen Javascript Logiker entfernt
- Park- und Attraktionsgeschichte haben nun einen eigenen Tab
- Für Geschichtseinträge (Historie) muss nun ein Typ ausgewählt werden