如何使用 Claude AI 計算多個專案中帶有 ToDo 標籤的未解決註釋數量

Question

我們的團隊至少有 16 個 Paratext 專案。我們需要知道每個 Paratext 專案中，新約每一卷書帶有 ToDo 標籤的未解決註釋（Unresolved notes）數量。我正在與 Claude Cowork 合作，試圖獲取這些資訊並將其放入試算表中。我自己可以透過在每個 Paratext  專案中開啟「註釋清單」（Notes List）視窗並適當設定篩選條件來獲取這些資訊。這樣做可以讓我今天得到數字，我不介意這樣做一次。但隨著我們追蹤團隊的進度，我將再次需要這些數字，所以我希望 Claude 能替我完成這件事，並且能夠重複執行。它一直無法得出與我在 Paratext 中看到的相符的數字。它在逆向工程資料結構方面遇到了困難。以下是它向我提出的問題： 
我想問開發人員的具體問題：

1. 當使用者篩選「未解決的待辦事項」（Unresolved To Do）註釋時，Paratext 如何確定每個線程（thread）的目前標籤？是：(a) 所有使用者檔案中所有 TagAdded/TagRemoved 的全域累積，(b) 僅根註釋（root comment）的標籤，還是 (c) 其他情況？
2. Paratext 如何確定一個線程是未解決的？是根註釋的 Status 欄位、任何使用者的 Status，還是專門的線程級欄位？
3. 篩選結果顯示的是來自所有使用者的線程，還是僅顯示登入使用者曾參與的線程？
4. 如果一個線程的根註釋已被刪除，它是否仍會出現在篩選結果中？

感謝您提供任何幫助。 

John Nystrom

Aitape West Translation Programme

SIL PNG 

機器翻譯自 English 顯示原文

Answer 1

既然提到了「根註釋」（root comment），我猜測這已經在執行了，但以防萬一，在計算任何其他內容之前，需要先收集具有相同線程 ID 的所有使用者的註釋，並按日期排序。這是 Paratext 對專案註釋線程的定義。在建立這個有序的註釋清單後，您就可以計算其他內容：

1. 目前標籤是透過在遍歷註釋時查看 <TagAdded> 和 <TagRemoved> 元素來確定的。它最初設計為允許註釋有多個標籤，但我認為透過 UI 實際上無法做到這一點，所以您可能只需要查看最後一個包含 <TagAdded> 或 <TagRemoved> 元素的註釋。
2. 沒有線程級別的資料。線程僅透過擁有相同線程 ID 的註釋而存在。要確定線程是否未解決，最後一個具有非空 <Status> 元素的註釋必須不是 "deleted"（通常是 "todo"）。
3. 是所有使用者。
4. 我不確定那意味著什麼。如果它的意思是第一個註釋的 <Status> 為 "deleted"，且沒有後續註釋更改狀態，那麼不，該線程將被視為已解決。

機器翻譯自 English 顯示原文

Comments

另外，請注意日期格式包含偏移量（即它們是本地時間）。它們不是 UTC。這意味著解析每個註釋的日期/時間時，必須考慮該偏移量，以確保排序正確執行。

機器翻譯自 English 顯示原文

Answer 2

也許這比看起來簡單。您可以為多個專案開啟註釋清單。
當「註釋清單」（Notes List）出現時，選取您的全部 16 個專案。然後將篩選條件設定為未解決（unresolved）和待辦（todo）。

我在 aArp、aMal 和 aSer 中得到了 353 個未解決的待辦註釋。

機器翻譯自 English 顯示原文

Comments

謝謝你，Steve。是的，我們可以像您展示的那樣做，並且隨時都可以這樣做。但我目前目標是為每個專案的新約每一卷書獲取單獨的計數，以便我們可以看到誰跟上了進度，誰落後了，並能夠在可更新的試算表中獲取這些計數。

機器翻譯自 English 顯示原文

---

雖然我非常喜歡使用（AI 編寫的）腳本在外部解決所有問題，去做 PT 從未打算做的事情...

我認為 Steve 可能發現了什麼。為什麼不建立一個版面配置（Layout），在 16 個單獨的視窗中開啟所有 16 個專案的註釋，然後將其儲存為新的版面配置。當您需要查看總數時，可以載入該版面配置，其餘時間則載入您的標準版面配置。

機器翻譯自 English 顯示原文

---

Mnjames，

我實際上確實有一個 Paratext 版面配置，完全做到這一點。我們當然可以查看每個專案的「註釋清單」（Notes List），看看有多少註釋是未處理的（針對目前的書卷）。但隨著我們預計將以這些語言製作迷你聖經（Mini-Bibles），我們需要所有書卷的這些資訊。我們需要這種資訊以一種能讓我們概覽整個團隊的形式，以便我們能看到大局和細節。讓我或另一位團隊成員為每一卷書執行該操作並手動將數字輸入試算表，以便我們能看到大局，這是不切實際的。

Paratext 曾經有一個「大局」（Big Picture）視圖，如果我記得沒錯，它提供了這些資訊，但幾年前被移除了。我非常喜歡它，並覺得我們的團隊需要它。當時 Paratext 的「負責人」（Owner）討厭它，並問我們是否足夠頻繁地使用它以證明保留在 UI 中的合理性。我屈服了，說「不，如果這對開發團隊是個問題，就把它拿掉吧」，但我現在後悔說了那句話。這是群組專案（cluster projects）管理員需要的這種類型的東西。 

機器翻譯自 English 顯示原文

---

感謝 @mnjames 的建議，我現在有兩個 Python 腳本來完成這項任務並建立試算表。我隨時可以再次執行這些腳本來更新試算表。如果有人對這些腳本感興趣，請告訴我。我會在下方貼上試算表的儲存格內容。 

透過查看這些數字，我們可以看出誰即將完成哪些書卷的註釋，以及誰還有漫長的路要走。這有助於我們回答像「要多久才能清完專案註釋的積壓工作，以便為這些語言出版迷你聖經？」以及「如果我們在特定日期同時出版所有迷你聖經，誰可能已經準備好哪些書卷可以出版？」這樣的問題。 

感謝所有幫助我思考這個問題的人，以及鼓勵我學習使用 Claude 函式（這些是 Paratext 本身無法做到的功能）的人。 

JN

書卷	aArp	aArpBT	aSno	aMal	bBar	bG1BT	bPou	bSum	cGoi	cOGBT	cRbr	cWol	dOpi	dOLBT	總計
MAT	8	10	5	6	89	29	123	617	27	11	39	12	110	320	1406
MRK		14	2	11	59	48	50	131	15	5	24	20	33	33	445
LUK	1	7	39	32	43	37	39	66	112	38	732	126	34	34	1340
JHN	1	9		6	132	72	151	530	89	42	128	107	162	240	1669
ACT	1	10	196	129	253	252	251	1236	280	252	830	651	250	250	4841
ROM	1	92													93
1CO	1														1
2CO	1							1							2
GAL	7	1	5	4	7	8	5	189	6	7	9	8	10	10	276
EPH		2	5	3	6	5	6	98		1	1	6	5	5	143
PHP		1		2		2	1	158				5	4	4	177
COL					6	4	8	67					34	32	151
1TH			3		1	1	1	84	1		1	2	3	3	100
2TH			1	1				55	1				3	3	64
1TI			4	2	4	3	1	15	6	3	4	7	3	3	55
2TI			11	1	1	1	1	19	6	1	4	4	1	1	51
TIT					1	1		7	3	1	1	2			16
PHM			1			1					1	1			4
HEB	15	5													20
JAS		1	1		16	12	5	50			2		5	5	97
1PE			2	2	3	4	4	848	6	6	7	5	4	4	895
2PE			3	2	4	5	7	373	6	5	3	4	4	4	420
1JN			2		1	1	1	21	2				1	1	30
2JN			4		1	1	1	3					1	1	12
3JN			1					1							2
JUD			4	4	5	5	2	199	4	3		2	4	4	236
REV	1	10	3	1	6	3	9	7	14	3	5	4	6	6	78
總計	37	162	292	206	638	495	666	4775	578	378	1791	966	677	963	12624

機器翻譯自 English 顯示原文