mklimek1/final-project

Final project for Technical Communication studies

Final Project

Notatki ogólne

Notatki ogólne 1.2

1. 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 :)
2. 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.
3. 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.
4. Jeśli coś trzeba dodać do glosariusza, wpiszcie hasło, ja to potem uzupełnię.
5. 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

Notatki ogólne 1.1

1. Wariant: British English 🇬🇧
2. Skróty isn't, don't itd. nie są tolerowane, z wyjątkiem zdania After all, you wouldn't drive a Ferrari to buy groceries, would you? w What is Markdown?
3. Oxford Comma: tak

Notatki ogólne 1.0

1. Najlepiej zacząć sprawdzanie od index.md w folderze głównym, a potem tekst i spis treści pokierują 🙂
2. 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)
3. 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.
4. W tekście znajdują się komentarze do Was w formacie <!-- -->! Dlatego lepiej sprawdzać w VSC albo w edytorze kodu w GitHubie.
5. 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.

Issues

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 ;)

Known issues

Konieczne

• uściślenie terminologii:
  • extracted -> imported
  • target -> output file
  • output -> output file

Wypadałoby

• 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

Ewentualnie potencjalnie możliwe

• dodanie backticków do nazw ustawień
• dodanie mini spisów treści w plikach results oraz w innych plikach o rozbudowanej treści

Solved issues

• 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 😄

---

Notatki @Justyna

OSTATKI DO SPRAWDZENIA

1. phrase-00-overview.md
2. phrase-01-settings.md
3. phrase-02-results.md
4. phrase-03-summary-and-recommendations.md
5. top-comparison.md
6. top-general-rec.md
7. top-conclusion.md

Stare notatki

1. 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" 😅
2. 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.
3. 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

Notatki @Monika

1. 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.
2. Jeśli masz jakieś pomysły dotyczące objaśnienia Markdowna laikom — śmiało komentuj!

Notatki @Marta

---

Pomysły na rozbudowanie

• 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...