- Jeśli znajdziecie jakieś terminy, styl, coś merytorycznego, co ma być do ujednolicenia W WIELU PLIKACH (por. Known issues), dopiszcie to do tych Known issues. Zajmię się tym na sam koniec, bo nie chcę Was obarczać znanym i nielubianym monkey-job :)
- Jest to wspomniane bezpośrednio w plikach, ale wrzucam uwagę też tu: niektóre formatowanie zastosowane w the test file nie działa w podglądzie GitHuba.
- Jeśli dalej jakieś ilustracje lub inne odniesienia do sekcji nie działają, dajcie znać. Obsidian jest za bardzo user-friendly i wyręcza w wielu kwestiach, co potem tworzy problemy w GitHubie.
- Jeśli coś trzeba dodać do glosariusza, wpiszcie hasło, ja to potem uzupełnię.
- W Comparison jest zmiana biegów w stylistyce w sekcji Discussion of the results — to z rozmysłem; to jest dyskusja, przedstawienie opinii, więc napisałem to bardziej po ludzku, a nie naukowym raportem
- Wariant: British English 🇬🇧
- Skróty
isn't, don't
itd. nie są tolerowane, z wyjątkiem zdaniaAfter all, you wouldn't drive a Ferrari to buy groceries, would you?
w What is Markdown? - Oxford Comma: tak
- Najlepiej zacząć sprawdzanie od index.md w folderze głównym, a potem tekst i spis treści pokierują 🙂
- Te rzeczy się NA PEWNO wysypią w podglądzie w GitHubie, ale nie w Visual Studio Code (VSC):
- zagnieżdżony HTML w "The test file" (Markdown-in-CAT-test.md)
- część formatowania MD w "The test file" (Markdown-in-CAT-test.md)
- skrypt JS w "The test file" (Markdown-in-CAT-test.md)
- NIE SPRAWDZAMY TREŚCI PLIKÓW FOLDERU RESOURCES. To są tylko pliki poglądowe omawiane we właściwej części tekstu :) Jeśli są tam jakieś błędy gramatyczne, stylistyczne, inne — nie jest to ważne dla sensu pracy.
- W tekście znajdują się komentarze do Was w formacie
<!-- -->
! Dlatego lepiej sprawdzać w VSC albo w edytorze kodu w GitHubie. - Starałem się to pisać w miarę prostym angielskim, dlatego styl może być trochę suchy z wyjątkiem
index.md
. Zwróćcie proszę uwagę, czy nie ma skrótów myślowych/klątwy wiedzy.
Tutaj wrzucamy ogólne problemy, które wymagają szerszej edycji lub redakcji.
Może to jest i overkill, ale stwiedziłem, że pogrupuję to wg wagi zmiany.
Lekcja z zajęć z Tomkiem ;)
- uściślenie terminologii:
extracted
->imported
target
->output file
output
->output file
- przecinki przed
because
— zrobię na sam koniec :) - zmienić nagłówki, zwłaszcza te z
—
, bo się psują odniesienia wewnętrzne - dać wycofanie do poprzedniej sekcji (zależne od tego, jak będzie wyglądać po publikacji)
- upiększacze jak obrazki w niektórych sekcjach — do wstawienia na etapie publikacji
- info na podstawie rozmowy z Justyną: gdzie znaleźć ustawienia importu/filtrowania .md w danym CAT
- dodanie backticków do nazw ustawień
- dodanie mini spisów treści w plikach results oraz w innych plikach o rozbudowanej treści
rozjechane podpisy pod obrazkami — w Obsidianie wyglądało ok, ale Obsidian wiele rzeczy robi po cichu sam, co potem GitHub czy VSC inaczej rozumieją; poprawię później
Oczywiście jeśli będziecie miały jakieś pytania, coś się nie będzie chciało otworzyć, albo coś się wysypie, a nie zaznaczyłem, że się wysypie — dajcie znać 🙂
Jeśli chodzi o komentowanie, to takie ogólne uwagi możecie robić przez Issues
w GitHubie, albo jeśli coś jest bardzo kontekstowe — za pomocą <!-- -->
w samym "kodzie". Jak wolicie 😄
phrase-00-overview.mdphrase-01-settings.mdphrase-02-results.mdphrase-03-summary-and-recommendations.mdtop-comparison.mdtop-general-rec.mdtop-conclusion.md
Część linków jest wstawiona do plików, których nie ma w repozytorium, bo je jeszcze piszę :) Dlatego linki do Phrase czy Tradosa nie zadziałają. Jest to wbrew pozorom "works as intended" 😅- Skup się proszę na tym, czy część dotycząca Markdowna i problemów Markdowna w CAT-ach jest zrozumiała dla osób nie mających z tym do czynienia.
- Jeśli masz jakieś pomysły dotyczące objaśnienia CAT-ów laikom — śmiało komentuj!
@Paweł 3: Chyba to już wszystko. Czytając część teoretyczną brakowało mi charakteru instrukcji (w sensie jak otworzyć dany plik w tym czy innym CAT-cie i co zrobić jak się nie otwiera, a wyrzuca błędy - chyba, że jednak przegapiłam), ale widzę, że instrukcje pojawiają się potem w uwagach dla tłumaczy i technical writerów. Dobrze się to czyta, ja przynajmniej rozumiem o co "kaman" i myślę, że dałabym radę, gdybym dostała zlecenie przetłumaczenia pliku .md w którymś z "kotów". Jak miałam jeszcze jakieś uwagi, dałam je w poszczególnych plikach. Daj znać, jak będziesz czegoś jeszcze ode mnie potrzebował. Pomogę. :-)
@Paweł: Poprawiłam, wg mnie dobrze się czyta i jest to zrozumiałe, napisane w przystępny sposób, dałam miejscami sugestie od siebie plus komentarze - do rozważenia, nie muszą być uwzględnione ;-)
Do rozważenia:
W jakim piszesz języku: BrE czy AmE (pisownia np. color)Czy stosować skróty typu "it's" czy "wouldn't" czy nie
Dzięki, przerzuciłem wytyczne do notatek :) — P
- Skup się proszę na tym, czy część dotycząca CAT-ów i problemów Markdowna w CAT-ach jest zrozumiała dla osób nie mających z tym do czynienia.
- Jeśli masz jakieś pomysły dotyczące objaśnienia Markdowna laikom — śmiało komentuj!
- Wymyślenie przypadków użycia: który CAT lepiej/gorzej
- np. Trados będzie słaby do baz wiedzy, a Wordfast zadziała jak marzenie
- uporządkowanie test file
- Przetestowanie w innych czytnikach Markdown
- kolejne CAT-y...