Actually, the "segmentation" comes from segmented memory management, which was integrated into in AT&T Unix. BSD went with paged virtual memory, and there we get "fault" from "page fault", which is an often correctable situation that is invisible to the application, but is sometimes an access violation.

So "segmentation fault" is a weird combination of terms.

And of course "core" is from "magnetic core memory" that nobody uses any more.

The SIGSEGV constant having come from AT&T Unix propagated into other variants, for the sake of source code compatibility, even though those other variants didn't use segmented memory.

I suspect that what happened was that hackers not working with segmented memory at all somehow adopted the "segmentation" term from the AT&T code and documentation, but did not warm up to the "violation" part, sticking with the "fault" terminology of their paged world.

The "Segmentation fault" string you see displayed by the shell comes from the strsignal function that maps signals to descriptive strings. I think that originated in BSD Unix. "(core dumped)" is locally generated by the shell if that flag is true in the process status.

Bash internationalizes that with gettext. Here it is in Hungarian:

  po/hr.po:msgid " (core dumped)"
  po/hr.po-msgstr " (jezgra izbačena)"

Estonia gets a cool one:

  po/eo.po:msgid " (core dumped)"
  po/eo.po-msgstr "(nekropsio elŝutita)"

Trivia: very early Linux kernel versions used 80386 segments for processes.