A3: a bunch of issues localizing content

[stepanjakl]

Hello team,

I've just been attempting to localize a team page and related pieces. However, there has been a few issues along the way.

First, in order to localize pieces I had to localize the page where the pieces are located on. I couldn't find and option to localize the pieces directly from the admin UI.

So I went through localizing the page and related documents, however I only got 3 team members that could be localized. There's around 20 of them overall.

Any ideas?

The next path I took was the command line:

node app team-member:localize

I got this error:

TypeError: Cannot read properties of undefined (reading 'force')
    at Object.flushInsertsAndDeletes (.../node_modules/apostrophe/modules/@apostrophecms/piece-type/index.js:1025:56)

I didn't hesitate and changed the function's force parameter it to the:

async flushInsertsAndDeletes(inserts, deletes, force = false)

Unfortunately, then I received this error:

BulkWriteError: E11000 duplicate key error collection: site-2-dev.aposDocs index: _id_ dup key: { _id: "clbdissdk0091hsgf2pe72b1f:en:draft" }
    at OrderedBulkOperation.handleWriteError (.../node_modules/mongodb/lib/bulk/common.js:1359:9)
    at resultHandler (.../node_modules/mongodb/lib/bulk/common.js:583:23)
    at handler (.../node_modules/mongodb/lib/core/sdam/topology.js:961:24)
    at .../node_modules/mongodb/lib/cmap/connection_pool.js:352:13
    at handleOperationResult (.../node_modules/mongodb/lib/core/sdam/server.js:567:5)
    at MessageStream.messageHandler (.../node_modules/mongodb/lib/cmap/connection.js:308:5)
    at MessageStream.emit (node:events:537:28)
    at processIncomingData (.../node_modules/mongodb/lib/cmap/message_stream.js:144:12)
    at MessageStream._write (.../node_modules/mongodb/lib/cmap/message_stream.js:42:5)
    at writeOrBuffer (node:internal/streams/writable:392:12)
    at _write (node:internal/streams/writable:333:10)
    at Writable.write (node:internal/streams/writable:337:10)
    at Socket.ondata (node:internal/streams/readable:766:22)
    at Socket.emit (node:events:537:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9) {
  driver: true,
  code: 11000,
  writeErrors: [ WriteError { err: [Object] } ],
  result: BulkWriteResult {
    result: {
      ok: 1,
      writeErrors: [Array],
      writeConcernErrors: [],
      insertedIds: [Array],
      nInserted: 0,
      nUpserted: 0,
      nMatched: 0,
      nModified: 0,
      nRemoved: 0,
      upserted: []
    },
    [Symbol(upsertedIds)]: undefined,
    [Symbol(insertedIds)]: undefined
  }
}

The same case for localizing images for example: node app @apostrophecms/image:localize

Any ideas?

Apostrophe version: 3.38.0

[boutell]

Hi @stepanjakl, the task you used there is intended for transitioning doc types from localized: false to localized: true which does not apply to your situation. That explains the errors when attempting to run it on a type that already has localization.

Let's back up to your original problem: the interface for localizing individual pieces was tough to find.

Here are screenshots showing how to do it. You'll need to use the three-dots menu, aka the "kebab menu," of extra functions either in the "manage pieces" view or the editor view of an individual piece.

[boutell]

(We don't currently have an option for localizing pieces in bulk.)

[stepanjakl]

Hello @boutell, thank you for your answer. Nice, I noticed that there is an option to localize pieces individually later. There's still the issue that not all related pieces were part of the page localizing process. It's not a substantial problem, I just wanted to let you know that it occured.

So I went through localizing the page and related documents, however I only got 3 team members that could be localized. There's around 20 of them overall.

I think they were all published as well at the time.

[boutell]

This might help:

A "related document" is a document that is explicitly related to the current document, via a relationship field in the document itself, a relationship field in an array field or object field schema, or a relationship field in a widget. This is intentionally narrow, it's done so that things without which your page really doesn't make sense also get localized, but we don't wind up agglomerating the entire site as "related" which happens pretty quickly if you go more than one step away.

In particular, a "piece page" that offers a paginated view of every piece is not considered to be "related" to every piece of that type. A piece that is two relationship steps away is also not considered "related" for this purpose.

My suspicion is that this would seem a lot more reasonable if we had a "batch localize" feature in the "manage pieces" view, which is a limitation we're working on.

[stepanjakl]

@boutell I see, that explains why it only offered those three team members as related documents. They were in a relationship to the team page for ordering purposes. Great to hear that localizing batch action is on the way. Thank you as always 👍