Turkish translation team

[wilzbach]

Ideally a language team should have at least two members, s.t. someone else can help to review or work on the Turkish translation.

Maybe @ozanselte, @kerdemdemir, @drtzack, or @zafer06 want to join the D translation team and can help @acehreli?

(See dlang-tour/core#132 for background details)

[zek]

Yes I would like to join.

[zek]

I just translated a few pages. ( https://github.com/drtzack/turkish ) I'm not sure If I'm going right.

Also Is it a literal translation? Can I make some additions?

I will talk about this also with @acehreli

[wilzbach]

I just translated a few pages. ( https://github.com/drtzack/turkish ) I'm not sure If I'm going right.

Unfortunately I don't speak Turkish, but it looks good :)

Maybe you can just make a PR to this repo so that @acehreli can review your work?

I wrote down my experiences from the German translation at the wiki, maybe that's helpful to you? The most interesting thing that I learned is to make a PR for every single file as it makes the reviewing a lot easier and smoother (I wrote a small helper script that simplifies submitting multiple PRs in case you as lazy as I am - see the wiki entry)

Also Is it a literal translation? Can I make some additions?

This question has come up before, see dlang-tour/core#454 for our previous discussion.

[wilzbach]

Hey guys,

I think I spread a bit of confusion, I hope I can help to clear it up:

1. I pinged a couple of Turkish speaking D enthusiasts because I believe the best way to handle such a project is to distribute the work load of translating and review (and yes I found you via the D map)

2. This repo forbids force-push and has CI checks enabled. So you can't commit here - you need to open a PR (that's checked by our friendly CI bot). That's why I invited you directly to the organization, because it's very hard to screw things up ;-)

3. The main idea was that someone volunteers and translates a file and opens a pull request (one per file!). On the pull request you can work collaboratively and point out problems in the translation and improve the translation iteratively. Please don't work on a separate fork, that breaks the entire spirit.

4. You can't and shouldn't translate tags, meta information and config files, the tour needs it. The markdown won't be shown to the readers & they can even install the tour locally (dub fetch dlang-tour). Convince yourself by looking at the current Turkish translation website: http://tour.dlang.io/tour/tr/welcome/welcome-to-d

5. Be aware that the friendly CI bot checks e.g. that your source code does compile and has a maximal length of 48 chars (for mobile devices)

6. For now @acehreli and @drtzack are the Turkish translation maintainers. However anyone can submit or review a translation.

7. Don't worry about your English. The most important thing is the Turkish content and you are all native speakers.

8. Translating technical content is very hard and it's difficult to figure out how or what to translate technical terms, but the easiest and best way is to do it together. Also I am pretty sure that @acehreli can advise on tough problems. For the German translation we often put the English word in parenthesis as e.g. immutable needs to be used in the source code and thus helps the reader to understand the keywords etc.

9. I saw that you discussed using a more "free" translation or even changing the content. I think @stonemaster answered this quite nicely at #454:

I didn't mean that it should be a 1-1 translation. Of course languages are different and there are ways to describe things in a language that wouldn't be possible in English for example. I just mean that the content should be more or less be the same. So if a paragraph talks about @safe it should follow the content and not add more (or remove) content that isn't present in the other languages. Writer's freedom should be the highest priority, as long as we talk about the same things in all languages.

I may only add that of course the tour in English isn't perfect and we highly appreciate if you submit a PR to dlang-tour/english if you find a confusing page or have other improvement ideas (there's an issue tracker as well).

10. Someone mentioned that the buttons are not in Turkish as of now. Yep we are working on the last glitches and this will be fixed quite soon (btw the GoLang Tour uses international buttons as well)

11. I hope that this helps to disentangle some of the confusion I spread. If not or you have further problems or questions we are happy to help out. Of course you can use this thread to ask further questions.

CC @zafer06 @nightmarex1337

[ahmetsait]

• I think about committing english version first and creating translation pull requests on top of it. It can simplify reviewing the translation - is that okay?
• If so should I make a one-shot commit that pulls all english repo files or commit english version of the file I'm working on and go one by one?
• How do we collaborate on PRs? By commenting on GitHub or also creating pull requests to the Head branch of PR owner's repo?
• What happens when we clash? I have a feeling that I won't agree on most translational decisions. Who has the last say on the matter, @acehreli ?
• I don't like 1-1 translations, they mostly feel awkward-unnatural and most importantly they make it too obvious that it was translated -which is something I hate as a reader. Thus, I prefer translating the meaning rather than text or sentences. The problem is, I can't help with the urge to extend explanations and go beyond what's present whenever I feel the text is unclear. I'm clueless at which point I should make a PR on english version or stay at my native field.
• There are some impossible-to-translate technical terms such as imperative. This forces me to use pseudo-translation words (like imparatif) or just english word itself. Because of this, I prefer writing the english phrase followed by turkish equivalent in brackets (see here). I would strongly recommend this approach but what's the consensus on this?

[acehreli]

@NightmareX1337, thank your very much for everybody's involvement. It looks like I won't be needed in this effort after all. :)

• No objections from me for committing the English version first.

• Yes, one-shot is fine as well. Of course, we need to keep an eye on changes to the originals somehow.

• I don't know best practices for PRs. I'm assuming pointing out typos and errors on the PR should be sufficient.

• I'm not an authority more than anybody else. :) For consistency though, I would be happy if the translation did agree with the text of the book "D Programlama Dili".

• We agree on not liking 1-1 translations. Have you seen the following discussion on Ddili?

  http://ddili.org/forum/post/12207

As I say there, I strongly recommend several steps of translation.

Regarding the need to extend the text, I recommend that it should be done in the original as well.

• I don't agree that there are impossible terms to translate. I've been involved in using Turkish in the contexts of C++ and D for more than a decade now and I've never failed to discover or invent Turkish terms. Just as an example, "imperative" already has an established translation in Turkish computer science: "emirli", which does appear in the dictionary of "D Programlama Dili":

  http://ddili.org/sozluk.html

I've found the following simple dictionary very useful during translation work:

http://www.langtolang.com/

Ali

[wilzbach]

@NightmareX1337, thank your very much for everybody's involvement.

I totally forgot that in my last message, sorry about that. Of course thank you very much @ all!!

I think about committing english version first and creating translation pull requests on top of it. It can simplify reviewing the translation - is that okay?

The reason why I haven't done this for the German version was

• to give the reviewer an "unbiased" view onto the text
• the English version isn't 100% perfect and especially while looking so closely during a translation one might find a typo etc.

but of course I can also see the advantages. It's your decision ;-)

If so should I make a one-shot commit that pulls all english repo files or commit english version of the file I'm working on and go one by one?

If you want to include the English version, I would include it in the PR per-file, because depending on your speed within two or three months there might have been small changes at the English content, but again this is your decision and I am just trying to help you to get started. Maybe you should start a new issue for this, s.t. there is a consensus among all of you on this?

How do we collaborate on PRs? By commenting on GitHub or also creating pull requests to the Head branch of PR owner's repo?

Whatever is most convenient/works best for you. From my experience

• especially for more controversial changes, comments are better
• comments are easier for reviewers (I can comment from the subway)
• comments are (a bit) more work for the submitter
• PRs to PRs are less noisy but also harder to track

What happens when we clash? I have a feeling that I won't agree on most translational decisions. Who has the last say on the matter, @acehreli ?

I hope that you will be able to find a consensus, but in such an unluckily case I think @acehreli has the most experience to reconcile and advise ;-)

I don't like 1-1 translations, they mostly feel awkward-unnatural and most importantly they make it too obvious that it was translated -which is something I hate as a reader. Thus, I prefer translating the meaning rather than text or sentences. The problem is, I can't help with the urge to extend explanations and go beyond what's present whenever I feel the text is unclear. I'm clueless at which point I should make a PR on english version or stay at my native field.

I can understand that and of course as @stonemaster said your freedom as a writer is the highest priority, but our idea was to keep the translation "in sync" and in most cases a change improves the English tour as well (and thus the other translations). Here are a couple of PRs I opened during the German translation:

• mention identity comparison - fixes #30 english#69
• Update memory.md english#2
• make the use of var more explicit english#1

There are some impossible-to-translate technical terms such as imperative. This forces me to use pseudo-translation words (like imparatif) or just english word itself. Because of this, I prefer writing the english phrase followed by turkish equivalent in brackets (see here). I would strongly recommend this approach but what's the consensus on this?

Yep I agree that mentioning the English word/phrase is often very helpful to the reader, whether it's imperative (imparatif) or imparatif (from imperative) is probably a style issue that is dependent on the language, so I can't help further here.

[...] As I say there, I strongly recommend several steps of translation.

Even the English version will always be WIP, because there can never be a perfect content. For the German translation we tried to get a "good" translation for each file as an initial version which then can be improved iteratively. One thing I like about this tour so much is that everything is Markdown and submitting an improvement is as easy as clicking on edit and modifying the Markdown content and hitting "submit".

I used Google translate (which impressing works pretty well), so to your quote:

English -> Multi-smelling Turkish English -> Less smelling Turkish English -> Turkish a little closer Turkish -> etc.

👍
The idea is that the review zone/buffer helps this process, s.t. all pages have a basic quality in an initial release.

[acehreli]

I like using the Turkish word in text, followed by the English word as in "emirli (imperative)".

My suggestion (which I benefit myself) for multiple translation steps is for the translating person before submitting a pull request. Coming back to one's own translation a couple of days later is very revealing. There is a tendency to translate from that version again. :)

[wilzbach]

My suggestion (which I benefit myself) for multiple translation steps is for the translating person before submitting a pull request. Coming back to one's own translation a couple of days later is very revealing. There is a tendency to translate from that version again. :)

The only potential disadvantage from this strategy that I see is that it could potentially lead to duplicate work. So either you would need to make a list of assignments per section which is less flexible or simply mark the PR as work-in-progress.

[acehreli]

No, there is no PR in what I'm saying. :) The translator (let's use the name Ali) translates and goes on with his life for a couple of days. He comes back to the translation after doing unrelated things, perhaps translating other chapters. The first translation reads horrible because it smells too much like English. Ali translates from Turkish to Turkish again and comes back to it after some time again and repeats several times. Only then the translation is acceptably Turkish at which time Ali creates a PR.

But that's a suggestion only. :)

[wilzbach]

No, there is no PR in what I'm saying. :) The translator (let's use the name Ali) translates and goes on with his life for a couple of days.

Yep I understood that and I like the idea.I was just trying to make the point that if Bob and Chris do the same, they will all do the translation for the same file, which might be demotivating and there are still many files to go. If you work alone it's easy to avoid concurrency problems, but in a collaboration I think you should try to communicate that one started on a translation, but as said there are many ways (open an issue and assign, open a WIP PR, make a simple list on the wiki,...)

[zek]

@acehreli @wilzbach
After almost 2 years there's no translation for dlang-tour. Also I am not able to use the tool that you advise. But I may create a new branch and PR for each commit such as #6.

Translation is hard and I am not the best person to translate correctly but I believe that it's better than nothing. After a bad translation someone can correct it. It is sad to see there is no Turkish translation.
I may try to translate as much as I can but some parts may stay in English. If that is okay for you, I can do it. Or we will wait for a someone to do it.

[wilzbach]

After almost 2 years there's no translation for dlang-tour.

Yep, pretty sad :/
It's almost time to upgrade the English tour content to the new D since then.

Also I am not able to use the tool that you advise. But I may create a new branch and PR for each commit such as #6.

I haven't used it in a while. What errors did you run into?
Then I guess do whatever is the easiest for you (it was just that I have observed that PRs with only one file get reviewed quicker).

I believe that it's better than nothing

Yes and incremental improvement can always happen easily via the "edit" button.

some parts may stay in English.

I would probably put a note at the end of the last Turkish page and linking back to the English content as this avoids the problem of copying the English "upstream" pages and keeping the translation in sync at least until the translation has started, but it's entirely up to.

If that is okay for you,

Not sure to which "you" are referring to, but it was a question to me.
Of course (:+1:), why would I object?

[zek]

I haven't used it in a while. What errors did you run into?
I couldn't even compile dlang tour :) Tried today in ubuntu 18.04. Downloaded dmd from official apt repository and compilation failed. So right now I'm translating over github.

Not sure to which "you" are referring to, but it was a question to me.
I just said it because I would like to follow contribution rules. Right now I have some free time every day and I thought I can use it for translating dlang-tour.

Ok then, I will continue to translate as much as I can do.

Thanks 👍

[zek]

Do we need anything to publish changes on the website? I can't see the changes in tour.dlang.org 26 Tem 2018 Per, saat 16:18 tarihinde Sebastian Wilzbach < [email protected]> şunu yazdı:

…

After almost 2 years there's no translation for dlang-tour. Yep, pretty sad :/ It's almost time to upgrade the English tour content to the new D since then. Also I am not able to use the tool that you advise. But I may create a new branch and PR for each commit such as #6 <#6>. I haven't used it in a while. What errors did you run into? Then I guess do whatever is the easiest for you (it was just that I have observed that PRs with only one file get reviewed quicker). I believe that it's better than nothing Yes and incremental improvement can always happen easily via the "edit" button. some parts may stay in English. I would probably put a note at the end of the last Turkish page and linking back to the English content as this avoids the problem of copying the English "upstream" pages and keeping the translation in sync at least until the translation has started, but it's entirely up to. If that is okay for you, Not sure to which "you" are referring to, but it was a question to me. Of course (👍), why would I object? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADTYew2FbJUZpZ4fJEeQnFqGC1NAfRYYks5uKcG3gaJpZM4JrWRu> .

[wilzbach]

Sorry the auto-deployment was down. No it should all go automatically, it typically takes 10m for a deploy and if that fails there's also a daily deployment see g..

https://tour.dlang.org/tour/tr/basics/imports-and-modules

However, only files listed in the configuration YAML will be deployed.
That's the reason why #9 isn't live

See: https://github.com/dlang-tour/turkish/blob/master/welcome/index.yml

You can preview this locally too btw, e.g.:

dub fetch dlang-tour
dub run dlang-tour --override-config="vibe-d:tls/openssl-1.1" -- -l .

(the override is only needed if your distro uses OpenSSL 1.1)