New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RDY] Update German translation. #780

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
10 participants
@fwalch
Copy link
Member

fwalch commented May 29, 2014

Following the steps in #767, I updated the German translation. All strings (incl. fuzzy) are now translated; make de.ck reports no errors. I also changed a few obvious things when I saw them (e.g. fixing some Leerzeichen in Komposita). I did not go through the translations line-by-line.

For vimscript-related messages, I changed the translations to use Dictionary, Number, List, etc. for the data types instead of a translation. Afaik, there is no German vimscript reference, and translating the data types might be a bit confusing and introduce ambiguity.

Most of the undo-related terms had not yet been translated, but the existing ones used "Wiederherstellung" for "undo". I don't think that really describes what undo does, but then again, I didn't want to call "undo file" "Rückgängig-Datei" or something. I used "Wiederherstellungsdatei" to be consistent, but maybe someone has a better idea for that.

Unfortunately, executing make de changed most of the po file (line numbers were updated), which makes this commit very big and probably hard to review :-(

@elmart

This comment has been minimized.

Copy link
Member

elmart commented May 29, 2014

Great. Thanks!
Unfortunately, I don't speak German, so I cannot review this.

Unfortunately, executing make de changed most of the po file (line numbers were updated), which makes this commit very big and probably hard to review :-(

Don't worry. Updating line numbers is a desired part of updating po files. Not too difficult to review either, when you see the only change is that.

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented May 30, 2014

existing ones used "Wiederherstellung" for "undo". I don't think that really describes what undo does

I'd agree, and what's worse is that it's not used like that in other applications. Instead, "wiederherstellen" is used for "redo" and "rückgängig" for "undo". Gvim also does it like this in its menu.

I'd say being consistent (with other applications) is important, since it's so common. It's probably confusing to a new user if "wiederherstellen" actually means "undo". So especially for messages like "Nothing to undo", I'd rather use "Nichts rückgängig zu machen" or similar.

I also can't think of a better translation for "undo file", that one's tricky. "Datei mit Aktionen zum rückgängig machen" would really describe it properly, but that's way too long of course. Maybe something like "Rückgängig-Hilfsdatei" or similar?

@kopischke

This comment has been minimized.

Copy link

kopischke commented May 30, 2014

+1 for “Rückgängig” instead of “Wiederherstellung” – @lethal-guitar pinpoints the issues with that. How about labeling persistent undo “Rückgängig-Schritte”, which gives us leeway for constructs like “Datei mit Rückgängig-Schritten” or “Rückgängig-Schrittedatei” (Mark Twain would be so proud).

@kopischke

This comment has been minimized.

Copy link

kopischke commented May 30, 2014

As an aside: is it just me, or will GitHub not show an actual, commentable diff of that file? I don’t really want to fork the whole repo and submit another PR for annotations…

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented May 30, 2014

It's not just you, it doesn't show diffs for me either..

@kopischke

This comment has been minimized.

Copy link

kopischke commented May 30, 2014

@lethal-guitar So what do we do? LGTM this then fork-and-PR again for further improvement suggestions? @elmart, @justinmk: any comments on the recommended procedure in this case? As far as I can tell, the fact make *.ck process generates a patch that is not diffable and commentable online will be a stumbling block whenever reviewing localization PRs…

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented May 30, 2014

What if I split the commits into two like so and squash them after review? The first commit is just the changes of make de (and would have to be reviewed offline, i.e. without Github diff view), the second has the manual changes and could be reviewed with Github (so with diff view/annotations).

I would fix the commit messages before I force-push this into this PR, of course.

Edit: Also, thanks for the suggestions! If we consider that the undo file stores a history of actions, maybe "Aktionshistorie" or something similar could also work? It's not as obvious as "Rückgängig-...", though.

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented May 30, 2014

What if I split the commits

@fwalch that sounds good!

@kopischke

This comment has been minimized.

Copy link

kopischke commented May 30, 2014

@fwalch the split would be helpful, sho’nuff – solves the issue of reviewing manual changes at least.

As to the translations of undo history, my two cents is to stick to “Rückgängig” in all cases: it’s unwieldy, but well established terminology. “Aktionshistorie” OTOH, albeit correct in the abstract, is unintuitive even to me, who is perfectly aware what context you suggested it in.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented May 30, 2014

Okay, I split the commits.

Regarding the undo-related terms: "Rückgängig-Schrittedatei", "Rückgängig-Hilfsdatei", "Rückgängig-Datei"/"Rückgängig-Informationen", ... -- do you have more ideas? Which term do you prefer?

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented May 30, 2014

@fwalch personally, I think "Rückgängig-Hilfsdatei" sounds best, but I'd still go with "Rückgängig-Schrittedatei" as it carries more information, and it's consistent with the general "Rückgängig-Schritte" as proposed by @kopischke. I also like "Rückgängig-Informationen", but with that, it's not clear that we're dealing with files.

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented May 30, 2014

Yes, definitely great work @fwalch! Aside from the undo/redo thing we discussed, and some minor things I noted in line comments, this all LGTM.

kopischke referenced this pull request in fwalch/neovim May 30, 2014

Update German translation (2).
* Translate missing and fuzzy strings.
* Don't translate vimscript datatypes.
* Fix some 'Leerzeichen in Komposita'.
* Some minor rewordings.
@elmart

This comment has been minimized.

Copy link
Member

elmart commented May 30, 2014

I think splitting into two commits with automatic and manual part, as you have done, is perfect.
We can do nothing about GitHub's not showing too big diffs.

But I wouldn't squash them again after reviewing. The same way it's useful for you now having them split could be useful for someone else in the future viewing project log / searching that file's history. So, I'd leave them split.

Also, as a final note, commit messages could be slightly improved, by making clear in the title how they differ. I mean, instead of using numbers (1) and (2), you could state the subtask you are doing in each commit. We use a convention here with task/subtasks separated by colons. That way, your commits would look like:

Update German translation: Automatic.
Update German translation: Manual.

or

Update German translation: Sync to XXX.
Update German translation: Improve translations.

You get the point.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 4, 2014

@lethal-guitar, @kopischke, thanks for your kind words and for reviewing all of this! I incorporated your suggestions, but did not squash the two "manual" commits (yet) to make reviewing easier (?).

A few notes:

I changed "Editiersitzung" to just "Sitzung", which is probably as clear as "Editiersitzung" or "Bearbeitungssitzung" in the context of a text editor. What do you think?

I updated all "editieren" to "bearbeiten", except in memline translations (starting at line 4117); the shortcut of "&bearbeiten" would collide with "&Beenden". Since this looks like GUI-related stuff, it will probably removed from NeoVim at some point anyway?

If this looks good, I will squash the two manual commits, update the commit messages as suggested by @elmart and mark this [RDY].

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 4, 2014

I changed "Editiersitzung" to just "Sitzung", which is probably as clear as "Editiersitzung" or "Bearbeitungssitzung" in the context of a text editor. What do you think?

LGTM

I updated all "editieren" to "bearbeiten", except in memline translations (starting at line 4117); the shortcut of "&bearbeiten" would collide with "&Beenden". Since this looks like GUI-related stuff, it will probably removed from NeoVim at some point anyway?

Those are the actions Vim suggest when a swap file exists, UI in the strict sense of “User Interaction”, tho not with a “G”. Not sure if and how Neovim will handle these, but until it does, I’d suggest we translate them as well as possible. If the shortcut is the problem, how about B&earbeiten? Gets you the “e” shortcut without the “editieren” part :).

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented Jun 4, 2014

@fwalch:

I changed "Editiersitzung" to just "Sitzung", which is probably as clear as "Editiersitzung" or "Bearbeitungssitzung" in the context of a text editor. What do you think?

I think "Sitzung" is absolutely fine here. I just added two small line notes, besides that, everything LGTM.

@kopischke

Gets you the “e” shortcut without the “editieren” part :).

That sounds good, and I would do it that way when creating a new translation from scratch. But we need to keep in mind that changing keyboard shortcuts might be confusing to a long-time user. Now, I don't think many people use these menu shortcuts anyway (I certainly don't), and you can do all of that much better using Vim commands. Still wanted to mention that, since in theory it might disturb some users.

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 4, 2014

@lethal-guitar

But we need to keep in mind that changing keyboard shortcuts might be confusing to a long-time user

If we use B&earbeiten, we keep the old shortcut, albeit lower case (does Vim even care?). Or am I missing something?

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented Jun 4, 2014

@kopischke oh you're totally right of course. My bad :)

Yeah, so +1 for that from me.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 4, 2014

Thanks! I now changed all occurences of "Auslagerungsdatei" to "Auslagerungsdatei (.swp)", except when the swap file name (foo.swp) is already contained in the message or (from what I could see in the source code) output immediately afterwards. I did add the ".swp" part if Vim complained that the file is not a swap file (E307, E310).

Can you have one more look? :-)

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 4, 2014

@fwalch will do this evening.

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented Jun 4, 2014

@fwalch once again, really great work, and far beyond the initial scope of your PR as well! The German translation is going to be perfect :)

I had one final note, aside from that, everything LGTM.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 4, 2014

One final question: sentence case ("Trotzdem bearbeiten") vs title case ("Trotzdem Bearbeiten") for the "GUI" messages (from line 4117, line 4297)?

Also, another related thing I just noticed: I'm going to upcase messages like on line 64 ("ein Puffer entladen" -> "Ein Puffer entladen") to be consistent.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 4, 2014

Actually, while I'm at it, I think I will go through the whole translation file before finishing this.

Scrolling through the file, I still stumble upon messages like "E73: tag Stapel leer." or "E78: Unbekannte Mark".

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented Jun 4, 2014

sentence case ("Trotzdem bearbeiten") vs title case ("Trotzdem Bearbeiten")

@fwalch personally I'd definitely go with sentence case, it feels more natural.
Maybe have a look how other software's localizations handle this? I don't have anything handy right now, but I can check later on.

@fwalch fwalch referenced this pull request Jun 4, 2014

Open

Improve output messages #809

@EinfachToll

This comment has been minimized.

Copy link

EinfachToll commented Jun 5, 2014

Hab auch mal stichprobenweise auf die Übersetzung geguckt, hier ein paar kleine Verbesserungen:

  • 6420 Komma vor „wenn“
  • 6387 Ausrufezeichen dahinter
  • 6375 Vi-kompatible
  • 6367 für die Onlinehilfe
  • 6347 und anderen (klein)
  • 6181 Zeilennummern? (Plural)
  • 6120 „der“ statt „von“
  • 6020 Byte (groß)
  • 5987 mit unterschiedlicher?
  • 5811 doppelt statt zweifach
  • 5778 FehlendeS?
@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 5, 2014

👍 on all of @EinfachToll's remarks but one:

6347 und anderen (klein)

Capitalization is allowed in this case (see Duden). Personally, I think the string better balances the other contributors with Braam when capitalized, but that is down to taste.

@EinfachToll thanks a lot for your contribution. One note: we’ve stuck to English for this thread to make it easier for the non-German speaking parts of the Neovim community to follow it, either now or later. Besides making it possible to pitch in on other aspects than the translations proper – as @elmart did –, the thread by itself might be of interest as it is the first major Neovim localization update effort (AFAIK).

@aktau

This comment has been minimized.

Copy link
Member

aktau commented Jun 5, 2014

One note: we’ve stuck to English for this thread to make it easier for the non-German speaking parts of the Neovim community to follow it, either now or later. Besides making it possible to pitch in on other aspects than the translations proper – as @elmart did –, the thread by itself might be of interest as it is the first major Neovim localization update effort (AFAIK).

Agreed, I'm not a native German speaker (though I do read and understand it, it's quite similar to my native language), but I do follow this thread. Keeping the discussions in English keeps it all more inclusive and allows others to learn from your efforts on how to go about stuff. For the rest I just wanted to say: great work!

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 5, 2014

For the rest I just wanted to say: great work!

OK, group hug, everyone 😁 With some extra pats on the back for @fwalch, who bears the brunt of this.

@lethal-guitar

This comment has been minimized.

Copy link

lethal-guitar commented Jun 5, 2014

@kopischke haha 😃

Yeah, that sounds good.

@EinfachToll

This comment has been minimized.

Copy link

EinfachToll commented Jun 5, 2014

@lethal-guitar: when I read „fehlende ']'“, I expand it neither to „fehlende schließende eckige Klammer“ nor to „fehlendes Zeichen“. I don't know why, but the neuter just feels more natural to me.
@kopischke Ok, I must admit I missed that remark.

So, both cases are apparently a matter of taste, so do what you think is best.

@saimen

This comment has been minimized.

Copy link

saimen commented Jun 6, 2014

Actually the first commit is still too big for me to comment on. Could you please split it up again so it can be commented?

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 19, 2014

Pinging @fwalch

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 20, 2014

I will continue working on this tomorrow.

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 20, 2014

@fwalch cool – thanks!

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 21, 2014

First of all, let me apologize -- I didn't want to let this unfinished for so long. Only yesterday I realized that it has been over two weeks (!!) already!

Again, a big fat "thank you" to all of you, @kopischke, @lethal-guitar, @EinfachToll -- all that was really left for me to do was typing 😀

A few remarks about the commits:

  • 1834, 1843, 4247: I didn't change this, because interrupt can be translated as "Unterbrechung" (see e.g. here).
  • 3596: I think "Änder." is used as an abbreviation for "Änderung", so I didn't change that.
  • 4568: I couldn't actually find any occurence of "Tasten-Code"?
  • 6226: This is shown when executing :undolist, so I think there are no changes needed here.
  • I changed "Ausdruck" (as in printing) to "Druck"; "Ausdruck" can also mean (and is used for) expression (as in regular expression). I should have left this for a follow-up PR, but I hope the change is not too controversial.

If one of you could have one final look for spelling errors, I would squash the "update after review" commits and mark this [RDY]. The new commits are fcceab0 and 3129ee7.

Stuff for a follow-up PR:

  • Use passive voice.
  • Resolve 1604 & 5956; I just didn't have any idea what to do here.
  • To get around the "fehlende '[': %s" problem, maybe change to "'[' fehlt: %s" for this and related messages.
  • Change all "in %s Zeile %d:" to "in %s, Zeile %d:"

Also see #809.

@saimen Sorry, that's not possible. The "Sync to XXX" commits are just the result of make de, though. To verify, you can try something like:

git checkout 3972f6cde741a03eb04a413f61983f2d768127c2
cd src/nvim/po
cp de.po de.po.new
make de
diff -u de.po de.po.new

That should hopefully show that there are no differences.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 25, 2014

As the last Travis build somehow failed and upstream master got new strings in the meantime, I pushed new commits. The ones not reviewed so far are fwalch/neovim@fcceab0 and fwalch/neovim@3129ee7 . One note: I translated "API metadata information" as "API-Metainformationen", which is shorter than "API-Metadaten-Informationen", but still very similar to the original string. Also a synonym for "Metadaten" according to https://de.wikipedia.org/wiki/Metadaten.

(Re "keeping up with master": did I do that correctly? I pulled upstream master, rebased it into my translation-de branch and force-pushed the new commits. I've seen messages like "... commented on an outdated diff" in Github issues before, but here, the commit annotations of the old commits are not shown anymore? You can still access them if you know the commit hash, e.g. fwalch/neovim@942203a . Also, strange that e.g. 942203a is a valid link when this has not been pulled yet.)

@kopischke

This comment has been minimized.

Copy link

kopischke commented Jun 26, 2014

Pinging @elmart, @aktau re. the “keeping up with master” question.

@elmart

This comment has been minimized.

Copy link
Member

elmart commented Jun 26, 2014

Regarding the rebase/keep-up-with-master issue, I think that once you've finished the review process, you should squash all commits doing actual changes, and leave only:

  • one commit doing the sync.
  • once commit doing the actual changes.

To do that:

  • Use git rebase -i to squash all the commits where you actually perform changes into one. Do this in your branch.
  • Update upstream/master.
  • Create new branch on upstream/master.
  • Sync (make de) and commit. That makes the first commit we wanted.
  • Rebase your previous branch onto the new one picking only the single commit with all your changes. That makes the second commit we wanted. Or, just cherry-pick that commit to the new branch.
  • Last, force-push to your public branch here.

Regarding github sometimes showing / sometimes not showing comments about lost commits, I'm in doubt too. Sometimes I see the "commented on outdated diff" thing and some other times comments get lost. I haven't found the pattern to explain this behaviour, though I haven't investigated it really. There should be some explanation somewhere, but I don't know it now, sorry.

@Hinidu

This comment has been minimized.

Copy link
Contributor

Hinidu commented Jun 26, 2014

I've seen messages like "... commented on an outdated diff" in Github issues before, but here, the commit annotations of the old commits are not shown anymore?

I think messages "commented on an outdated diff" is visible if code in that diff was changed in the one of the later commits and old commit is still in PR. After force-push comments dissapear because hash of the old commit was changed during rebase.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 26, 2014

@elmart: Thanks for the steps! Since I performed an intermediate "Sync" commit (so the original commit history was: sync, improve translations, sync, improve translations), cherry-picking the combined improvements raised a lot of merge errors. Maybe I could've done something with commit reordering, but I ended up doing it like this:

  • Copy de.po file with all changes (so basically this + @kopischke's comments) to de.po2.
  • Update upstream/master.
  • Create new branch on upstream/master.
  • Delete nvim.pot (otherwise "POT-Creation-Date" might be off).
  • Sync (make de) and commit. That makes the first commit we wanted. Remember the "POT-Creation-Date".
  • Copy de.po2 to de.po, change the "POT-Creation-Date" to the previous one and commit. That makes the second commit we wanted.
  • Last, force-push to your public branch here.

Not the most elegant workflow, but pretty easy in this case (all modifications are in one single file).

@Hinidu: Makes sense, thanks!

Some final checks: make de.ck and msgfmt -c de.po run without warnings, make de doesn't change the file, and there are no more fuzzy or empty translations. Marking this [RDY]. Thank you all for your help!

Edit: Even though the build failed, the committed changes are 100% identical to this build (just different commit message), which was successful. I think I can't start a new build without pushing once more.

Edit 2: The build error is caused by ASAN as reported in travis-ci/travis-ci#2449, so not related to this pull request.

@fwalch fwalch changed the title [RFC] Update German translation. [RDY] Update German translation. Jun 26, 2014

Update German translation: Improve translations.
* Translate missing and fuzzy strings.
* Fix grammatical errors.
* Rewordings for consistency.
@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 26, 2014

@elmart: Are translations actually used/checked/... during the build process? If not, [skip ci] could be added to translation-related commits to avoid unnecessary Travis builds.

@elmart

This comment has been minimized.

Copy link
Member

elmart commented Jun 26, 2014

@fwalch: No, message translation build it not integrated into overall build. In the sense that it doesn't check messages at every build. Such a thing doesn't seem to be desirable, as fixing messages at every commit would require the same person to have knowledge about all translated languages, which clearly is not possible. So, translation is a task that is better done in big blocks, at certain points in time, for different languages by different people.

That said, I think it's a good thing to maintain current policy about requiring all contributions to pass Travis. If translation tasks shouldn't affect build status, and they do (as it is happening to you now), that is caused by another problem that should be fixed. Right now, it seems that the clang-asan build randomly fails from time to time with the "could not allocate" error. That should be investigated and fixed in a different PR, IMO.

@fwalch

This comment has been minimized.

Copy link
Member

fwalch commented Jun 26, 2014

@elmart: I thought that maybe the syntax of .po files was verified or something. But, as you said, translations are only changed rarely, so there wouldn't be much benefit in that. It might be nice to have some kind of statistics for each language (i.e. how many untranslated strings there are) that indicate where translation contributions are needed. Such a report could be generated during the build process.

@elmart

This comment has been minimized.

Copy link
Member

elmart commented Jun 27, 2014

It might be nice to have some kind of statistics for each language (i.e. how many untranslated strings there are) that indicate where translation contributions are needed.

Yes, that would be nice. You can get that info running the default target of the localization build, this is, bare make while in the po/ directory. That will give an output that includes a list of the form:

OLD_PO_FILE_INPUT=yes msgfmt -v -o af.mo af.po
996 translated messages, 198 fuzzy translations, 181 untranslated messages.
OLD_PO_FILE_INPUT=yes msgfmt -v -o ca.mo ca.po
1252 translated messages, 76 fuzzy translations, 47 untranslated messages.
OLD_PO_FILE_INPUT=yes msgfmt -v -o cs.mo cs.po
768 translated messages, 375 fuzzy translations, 232 untranslated messages.
OLD_PO_FILE_INPUT=yes msgfmt -v -o de.mo de.po

It shouldn't be difficult making a script to parse that output and generate a nice report.

Such a report could be generated during the build process.

A new target could be added to the build invoking the script mentioned above. Or, if simple enough, it could be inlined within the Makefile instead of having a separate script.

We could run such a target periodically and export results to some public place. But, as I said before, I wouldn't include it on every build, cause most builds (development ones) don't touch localization and that would just add more burden.

Two more notes on possible actions:

  • There is more detailed info about each file through make <language>.ck that can be seen in check.log. That is done for every file with make check. Perhaps that info could also be merged with the above to generate the report.
  • Targets install, uninstall, prefixcheck are still to be fixed. They are meant to copy/delete the generated *.mo files to/from the proper system location. That is currently broken, as the proper system location was previously determined by autoconf. Now, this should be properly integrated with cmake so that it tells where to put files. Then, I think at least update-po / all / install / uninstall / report should be integrated with the overall build so that they can be called from the main build / directory. @jszakmeister should have a look into this to determine the best way to do that.

@justinmk justinmk added the l10n label Jun 29, 2014

@justinmk

This comment has been minimized.

Copy link
Member

justinmk commented Jun 29, 2014

@elmart Updated the wiki page, thank you.

We are also considering using a bot to generate doxygen a few times per week: neovim/neovim.github.io#48 . Maybe the bot's travis account can be used for the localization checks you have outlined.

Targets install, uninstall, prefixcheck are still to be fixed

Created an issue for this: #902

@jszakmeister

This comment has been minimized.

Copy link
Member

jszakmeister commented Jun 30, 2014

@jszakmeister should have a look into this to determine the best way to do that.

I can take a look at converting it to CMake. I took a quick look yesterday, and I think most--if not all--of it can be handled via CMake's gettext support. The only catch is all the little conversions Vim is doing to some of the .po files to produce others, but at least it's all pretty straight-forward.

justinmk added a commit that referenced this pull request Jul 1, 2014

@justinmk

This comment has been minimized.

Copy link
Member

justinmk commented Jul 1, 2014

Merged. Thank you @fwalch and reviewers!

@justinmk justinmk closed this Jul 1, 2014

@fwalch fwalch deleted the fwalch:translation-de branch Jul 10, 2014

Grimy pushed a commit to Grimy/neovim that referenced this pull request Jan 7, 2015

Merge pull request neovim#780 from rxwen/master
flush the options_file before start the ycmd server

dwb pushed a commit to dwb/neovim that referenced this pull request Feb 21, 2017

tests: fix 'AddExprCallback with changed windows inbetween' (neovim#780)
* tests: fix 'AddExprCallback with changed windows inbetween'

* fixup! tests: fix 'AddExprCallback with changed windows inbetween'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment