ConwayLife.com

When trying to translate some articles into Chinese, I noticed the fact that many terms does not have a common translation, (e.g. what should "beehive at beehive" be translated into?) This makes it hard to introduce CA to Chinese people interested in CA.

Since there are quite a few Chinese users on the forum, is anyone interested in joining the discussion to determine a consensus of translation of CA terms?

Apparently closely related discussion: viewtopic.php?f=12&t=2333 "Help with names"

Hunting wrote: September 25th, 2024, 6:41 am [...] (e.g. what should "beehive at beehive" be translated into?) [...]

For objects that have an apgcode in particular, I'd suggest to stick to apgcodes for a while (even regardless of the language of your local community). Maybe with very few exceptions like block, blinker, glider, which obviously have to have names. For larger/compound objects, just use apgcodes and wait enough time for a consensus to emerge naturally.

If you want to describe an object (e.g. explain how xs12_o4q552z01 can be viewed as "two beehives joined to each other"), then you can just write a FLMD (full length multiword description), using whatever tools are available in the natural language.

Alternatively, if there's enough interest to attempt a larger project, something equivalent to Nicolay Beluchenko's translation of the Life Lexicon into Russian would certainly be an option. We could certainly put a link right next to Beluchenko's, for a completed downloadable translation of current Lexicon entries into Chinese. That's a lot of work, but at the same time it's a lot more manageable than (say) a Chinese version of all current LifeWiki articles -- and it would get easier as you went along and made systematic decisions about each new term as it came up in the list.

We never got as far as hosting the individual Russian pages separately in conwaylife.com/ref/lexicon/lex_home_ru, but there's no reason that couldn't be done for both the Russian and Chinese pages.

One main reason it _hasn't_ been done for the Russian pages is that the translation was done in 2006 and hasn't been updated since -- which means that a large number of entries in the Russian Life Lexicon simply aren't true any more.

We have the same problem in the English Life Lexicon these days, of course, to a smaller extent -- and in the long term we'll have the same problem with any translations that anyone does. But that doesn't necessarily mean that projects like this should be avoided! It just means that translations need to be clearly labeled with their last update date, as the English and Russian Lexicons are.

Ideally we'd get another Lexicon update done, and then do the translation to Chinese. Not sure if that's very likely right now -- there haven't been a lot of volunteers showing up to do the systematic update work that would be needed -- e.g., no pull requests have been sent in to the Lexicon repository, and no issues have been reported there. But that could change any time, I suppose!

dvgrn wrote: September 25th, 2024, 8:18 am [...] the translation was done in 2006 and hasn't been updated since -- [...]

I do not see this as a significant problem. I think it is more interesting and useful to have a fixed version available.

I have an old release of Life Lexicon bookmarked, preserved in the archived form:

• the home page of Stephen Silver's Life Lexicon
• Multipage HTML version

When for some reason I need a linkable definition, I'm more likely to look in the old version first, and to link to the old version if it's there.
I don't feel like I'm losing much this way.

confocaloid wrote: September 25th, 2024, 7:42 am Apparently closely related discussion: viewtopic.php?f=12&t=2333 "Help with names"

Hunting wrote: September 25th, 2024, 6:41 am [...] (e.g. what should "beehive at beehive" be translated into?) [...]

For objects that have an apgcode in particular, I'd suggest to stick to apgcodes for a while (even regardless of the language of your local community). Maybe with very few exceptions like block, blinker, glider, which obviously have to have names. For larger/compound objects, just use apgcodes and wait enough time for a consensus to emerge naturally.

If you want to describe an object (e.g. explain how xs12_o4q552z01 can be viewed as "two beehives joined to each other"), then you can just write a FLMD (full length multiword description), using whatever tools are available in the natural language.

I disagree for the following reasons:

• This reduces pronounciability. Having to stop in the middle of a sentence and read something letter by letter is annoying.
• Apgcodes is ambiguous. I know systematic names are ambiguous too, but it's easy to tell "block on table" and "table on block" are the same thing, while most people can't immediately tell the apgcodes of two orientations of an object unless they are very familiar with apgcodes.

hunting wrote:Apgcodes is ambiguous... most people can't immediately tell the apgcodes of two orientations of an object unless they are very familiar with apgcodes.

That's incorrect. The apgcode (and any other Extended Wechsler Format Canonical Form based encoding) is, by definition, the same for all orientations and phases.

From https://conwaylife.com/wiki/Apgcode#Encoding_objects:

In order to enforce a canonical form, there are further rules regarding encoding:

The leftmost column and uppermost row must each contain at least one live cell. (This gives a canonical position.)

A canonical orientation and phase must be determined. For example, with the caterer (p3 oscillator with no symmetry), there are three phases and eight orientations, so we have 24 possible encodings. A total order on these encodings is defined as follows:

• Shorter representations are preferred to longer representations;

• For representations of the same length, lexicographical ASCII ordering is applied, and preference given to earlier strings.

This gives, for any still-life, oscillator or spaceship, an unambiguous canonical code to represent the pattern.

By that definition, for two apgcodes a simple compare will tell you if they are different or the same, and establish the order. Adding such encoders/decoders should be a trivial exercise for any Life utility or library if not already there.

And there's no reason that multiple names, like "Block on Table" and "Table on Block" can't have the same apgcode. (See, for example, "Eater", "Eater-1" and "Fishhook") And there's nothing that says that "xs10_32qr" can't be pronounced "Block on Table". (Work with such encodings enough, and you can start to see them in just that way.)

There's also an explanation on the Catagolue website, if that helps: /help/wechsler.txt

It also occurs to me that it there's no reason to do an exact translation of a name, and then impose it forever. The object names in English are fanciful at best, an sometimes it takes some effort to see the connection. Does "Beehive" really look like a beehive? Given that Chinese uses an ideographic orthography and a different cultural background, Life bitpatterns might appear to be similar to Chinese characters that have a different meaning. Better to just use unambiguous codes and let the colloquial names evolve naturally.

hkoenig wrote: September 27th, 2024, 9:42 am It also occurs to me that it there's no reason to do an exact translation of a name, and then impose it forever...

Makes sense. On the other hand, this also is going to depend on how ambitious and all-at-once the translation project is.

If a Chinese translation of the Life Lexicon ever gets created, for example, then presumably the translations will at least be consistent within that entire set of definitions.

Maybe it will make sense to use a non-exact translation for a lot of terms where the original English-specific pun or wordplay is really bound to be lost in translation anyway. Maybe "honeycomb" is a better translation to use than "beehive" -- 蜂巢 or 蜂窝 instead of 蜂箱 -- not that I would really know if any of those are the right choice. E.g., there could easily be cases where something that technically means "beehive" is really talking about something irrelevant like a beehive hairstyle -- which would make that a really poor translation!

Anyway, when those kinds of choices are made, a really useful way to standardize these definitions would be to include the English term in the definition:

" 蜂巢 (英语 'beehive')" ..."

hkoenig wrote: September 26th, 2024, 7:44 pm That's incorrect. The apgcode (and any other Extended Wechsler Format Canonical Form based encoding) is, by definition, the same for all orientations and phases.

My bad.

(Work with such encodings enough, and you can start to see them in just that way.)

I think you didn't get my point. Most people aren't computer nerds, using apgcodes in articles will only lift the threshold for people to read through an article.

The point I want to make by mentioning the "block on table" example is, some untrained eye scanning through a CGOL-related article will have to pause while reading a sentence, paste the apgcode into Golly (which he/she does not necessarily have), and run a script to know what it's talking about. This is not very friendly to someone who may be interested in CGOL.

It also occurs to me that it there's no reason to do an exact translation of a name, and then impose it forever. The object names in English are fanciful at best, an sometimes it takes some effort to see the connection. Does "Beehive" really look like a beehive? Given that Chinese uses an ideographic orthography and a different cultural background, Life bitpatterns might appear to be similar to Chinese characters that have a different meaning. Better to just use unambiguous codes and let the colloquial names evolve naturally.

Maybe it will make sense to use a non-exact translation for a lot of terms where the original English-specific pun or wordplay is really bound to be lost in translation anyway. Maybe "honeycomb" is a better translation to use than "beehive" -- 蜂巢 or 蜂窝 instead of 蜂箱 -- not that I would really know if any of those are the right choice. E.g., there could easily be cases where something that technically means "beehive" is really talking about something irrelevant like a beehive hairstyle -- which would make that a really poor translation!

The Chinese CA community is not big enough to be self-sustaining AFAIK, in this case it's probably a good idea to keep the translation consistent with the mainstream community instead, so that terms won't be much of an obstacle when we need to refer from the English community.

In fact, some original terms arising from the Chinese CGOL community already exists. For example, a widely accepted translation of "puffer" is "洒水车" instead of "河豚". I'm not saying that we should not accept these translations, but whatever the accepted translation is, we should canonicalize them in order to make translation and discussion between communities more convenient. The list can change over time if some translation was found to be inappropiate or there's a better translation, but it should be established first.

In the case of beehive, I haven't seen anyone translating it to "蜂箱" instead of "蜂巢/蜂房".

Hunting wrote: October 1st, 2024, 4:40 am [...] Most people aren't computer nerds, using apgcodes in articles will only lift the threshold for people to read through an article. [...]

I don't know whether you are planning to actively participate in setting up / maintaining a local community of people interested in CGoL/CA.

In that case, I think it may be better to intentionally keep "the threshold" sufficiently high. (Just so that maintainers, including yourself, will not be quickly overwhelmed by a stream of overenthusiastic newcomers and the constant need to explain the same basic things again, and again, and again).

Instead of trying to "explain CGoL to everyone" directly, it may be better to explain CGoL to those people who already understand and accept the basic idea of "doing it yourself". (And then let those people explain stuff to other people.)

Hunting wrote: October 1st, 2024, 4:40 am [...]
The point I want to make by mentioning the "block on table" example is, some untrained eye scanning through a CGOL-related article will have to pause while reading a sentence, paste the apgcode into Golly (which he/she does not necessarily have), and run a script to know what it's talking about. This is not very friendly to someone who may be interested in CGOL.
[...]

I think that depends on how you write said CGoL-related article.

It should be possible to write in such way that your readers will not have to paste any apgcodes in Golly or anywhere else, while at the same time using apgcodes to refer to CGoL objects without widely accepted names in the language of your local community.

When you are mentioning some object for the first time, you can show its image, with apgcode in the caption.

imaginary part of an imaginary article wrote: ...

Code: Select all

x = 12, y = 7, rule = B3/S23
2ob2o$2ob2o2$6b2o2b2o$6b2ob2o$b2o8bo$b2o!

...
3139 ticks later, the above collision settles into 13 escaping "gliders" (objects with apgcode xq4_153) and a large stationary constellation containing a still-life with population 10 and apgcode xs10_32qr:

Code: Select all

#C A 10-bit still life
#C apgcode xs10_32qr ( https://catagolue.hatsya.com/object/xs10_32qr/b3s23 )
#C Niemiec's identifier 10.25 ( https://conwaylife.com/ref/mniemiec/p1.htm#p1-10 )
x = 4, y = 5, rule = B3/S23
o2bo$4o2$2o$2o!

...

confocaloid wrote: October 1st, 2024, 7:00 am

Hunting wrote: October 1st, 2024, 4:40 am [...] Most people aren't computer nerds, using apgcodes in articles will only lift the threshold for people to read through an article. [...]

I don't know whether you are planning to actively participate in setting up / maintaining a local community of people interested in CGoL/CA.

In that case, I think it may be better to intentionally keep "the threshold" sufficiently high. (Just so that maintainers, including yourself, will not be quickly overwhelmed by a stream of overenthusiastic newcomers and the constant need to explain the same basic things again, and again, and again).

Instead of trying to "explain CGoL to everyone" directly, it may be better to explain CGoL to those people who already understand and accept the basic idea of "doing it yourself". (And then let those people explain stuff to other people.

The CGOL community exists to explore CGOL, not the reverse. I don't care about what people are in the community if more discoveries can be discovered.

The broader audience who does not intend to explore CA also have the right to know about CA researches.

Hunting wrote: October 13th, 2024, 6:10 am

confocaloid wrote: October 1st, 2024, 7:00 am [...] Instead of trying to "explain CGoL to everyone" directly, it may be better to explain CGoL to those people who already understand and accept the basic idea of "doing it yourself". (And then let those people explain stuff to other people.) [...]

The CGOL community exists to explore CGOL, not the reverse. I don't care about what people are in the community if more discoveries can be discovered.

The broader audience who does not intend to explore CA also have the right to know about CA researches.

I think that is a rather short-sighted attitude. Which discoveries / accomplishments are feasible, depends on the people in the community, and on what those people can do (within the existing environment). That, in turn, depends on the existing environment.

If you (as a hypothetical maintainer) let your local community be flooded by a constant stream of newcomers (who probably got some not-quite-correct impression about the field from oversimplified articles, and who don't even think that there is an expectation of lurking around for a while / searching for what is known before posting), that means that some of those few people who _could_ engineer / discover new stuff, will instead have to spend time and efforts dealing with that stream of newcomers, explaining basically the same things repeatedly. Sooner or later, many of the most productive/helpful members of your community will "burn out" and disappear, one by one.

People who are "interested but not invested" definitely should be allowed to read about the current state-of-the-art, about what is known, etc. However, here comes the choice. Either you are an "invested" enthusiast (and then you should be prepared to spend some efforts and DIY many things, you should be prepared to search for what is known before posting, etc.) Or you are just a reader/observer.

My point is basically, do not oversimplify things when you are trying to explain stuff.
For example, if there is an important distinction, keep it; do not try to "hide things under the carpet".

Re: the discussion of apgcodes and common names: in case if there is no (yet) a common name in your language for some object, then my suggestion would be to avoid inventing *any* name. Simply let such objects remain unnamed, until and unless some name naturally appears and becomes common in the local community.
For the purpose of writing an article explaining stuff to others, most names are unnecessary. You can show the small objects directly (e.g. as pictures); you can introduce apgcodes, or you can instead write short descriptions of those objects (that are unambiguous within the article), etc.