Wpis z mikrobloga

@MacDada: dzięki, zaraz zacznę poprawiać to co wypunktowałeś i podzielę ten kod na 2 pliki jeden z kodem, a drugi nagłówkowy - nazbierało się już trochę deklaracji funkcji, typedefów itp. Pierwsza styczność z Gitem i żeby zaktualizować jeden plik zrobiłem chyba z 5 commitów ( ͡° ͜ʖ ͡°)
@MacDada: zaraz zrobię poprawki tych warunków o których napisałes. Muszę przyznać, że tak zorganizowany kod czyta się łatwiej :) gdyby jeszcze funkcje nie były porozrzucane w losowej kolejności... :D
Co masz na myśli mówiąc o zapisywaniu komunikatów do stałych? Mam zrobić funkcję, która po zapytaniu o konkretny komunikat (np. finishgamemessage) zwróci ten komunikat w odpowiednim języku bazując na wysłanej/zapisanej gdzieś zmiennej local albo language?
@GlenPL: Jak do każdego komunikatu zrobisz funkcję, to się tych funkcji narobi od groma.

Nie wiem jak to sensownie w C++ uzyskać, ale najfajniej jakbyś miał plik ze wszystkimi tekstami i jedną funkcję, która na podstawie klucza i przekazanych parametrów przetłumaczy Ci komunikat.

gotowy_komunikat_do_wyswietlenia = translate(nazwa_komunikatu, parametr1, parametr2)
Liczba tych dodatkowych parametrów powinna być dowolna – tzn zależna od komunikatu.

W jednych nie będziesz miał żadnego, np tu:

Gratulacje, wygrałeś!
W
@MacDada: tak, mówię: "funkcję, która po zapytaniu o konkretny komunikat (np. finishgamemessage) zwróci ten komunikat w odpowiednim języku bazując na wysłanej/zapisanej gdzieś zmiennej local albo language", nie mam zamiaru robić do każdego komunikatu osobnej funkcji - to była by katorga, na dodatek dodanie nowego komunikatu to mnóstwo nowego kodu.

"Gratulacje, wygrałeś!" da się zrobić bez problemu, "Twoje imię to %s, potwierdzasz?" do sprawnego zakodowania funkcji obsługującej %s musiałbym chyba użyć kilku
@GlenPL: Na codzień piszę w PHP i zrobiłbym to w ten sposób:

http://pastebin.com/qRCcsxsS

Tzn nie do końca bym tak zrobił, bo pisałbym klasę, nie używał globali, etc – ale proceduralnie tak to wygląda.

Jeśli chcesz zahardkodować po prostu komunikaty, to zrób po prostu stałe i trzymaj w nich formaty:

// nie jestem pewien czy OK składnia, musiałbym sprawdzić, ale czaisz ideę
#define LANG_CONFIRM "Twoje imie to %s, potwierdzasz?"


// gdzieś gdzie
@MacDada: ok, łapię Twoją koncepcję. Niestety w c++ nie ma kontenera słownika, max co można wyciągnąć na kontenerach z STL to map - kontener którego każdy element jest parą , jakby się zastanowić można trzymać kontener w kontenerze i wtedy mieć taką konstrukcję (kurcze, narysowanie tego może być trochę trudne i ciężkie do zrozumienia dla Ciebie jeśli nie znasz zasad działania kontenerów z STLa):

http://pastebin.com/5ZFztSQu

Przepraszam za to co właśnie zobaczyłeś,
@GlenPL: Jak nie wiesz jak sensownie robić słowniki, to nawet wielki switch nie będzie jakimś halo. W środku loc_message po prostu switchami/ifami zwróć odpowiedni komunikat.

To co ja u siebie miałem to tablica dwuwymiarowa (słownik w słowniku), żeby właśnie móc wygodnie wybierać dla klucza i języka na raz, ale w sumie to można to zapisać jako po prostu IFy z językami i IFy z formatami w środku lub odwrotnie.

Obczaj to,
@MacDada: Z kolei language trzymaj sobie jako jakąś globalną zmienną, bo inaczej przy każdym tłumaczeniu będziesz musiał ją przekazywać, a to niewygodne i tak czy siak skądś brać wartość będziesz ;)
@GlenPL: No i jak dotąd nie miałeś w ogóle opcji tłumaczenia komunikatów – ale myślę, że to fajny challenge i jak już wyczaisz dobry sposób, to będziesz go używać też w innych programach (zwłaszcza jak jeszcze listę komunikatów byś trzymał w jakimś oddzielnym pliku :))
@MacDada: language nie musi być zmienną globalną, można przecież napisać to obiektowo i język trzymać jako pole obiektu. Teraz poprawię rzeczy które wypunktowałeś mi po ostatnim commicie, poczytam linki które podesłałeś i zastanowię się, jak rozwiązać ten słownik. Jeśli to by była, tak jak wcześniej pokazałem, mapa w mapie to można by było nawet napisy trzymać jako .txt i przy otwieraniu programu wywoływać funkcję która tworzy kontener przechowujący je w ramie.
language nie musi być zmienną globalną, można przecież napisać to obiektowo i język trzymać jako pole obiektu.


@GlenPL: Zgadza się, jak proponuję zmiany to nie proponuję obiektowych tylko proceduralne – bo nie wiem na ile ogarniasz OOP ;)

Co do samej implementacji, szybki google znalazł mi np to:

http://doc.qt.io/qt-5/qtranslator.html

Możesz skorzystać z gotowca i zająć się innymi rzeczami lub podrążyć temat w ramach nauki – jak wolisz :)
nie wiem jeszcze jak to jest z tymi variadic functions, ale mam nadzieję, że da się jakoś te argumenty roboczo ładować do kontenerów, bo STLowe kontenery w porównaniu do trzymania danych w stylu c to w wygodzie i przejrzystości jest niebo a ziemia :)