[Umbrella] Improve bulk document ingestion UX, recovery, and advanced indexing settings

[earayu]

Context

A bulk upload of a deeply nested, document-heavy learning-material corpus exposed several usability and recovery gaps across document ingestion. This is an umbrella issue to preserve the feedback and provide a place to split follow-up work. It is tracking only; no implementation is implied by filing it.

Answer quality remains the primary product priority. The items below are workflow improvements that can reduce manual work and make ingestion failures easier to understand and recover from.

Problems observed

1. Folder upload and selection

• Deep directory trees are cumbersome to upload through repeated file picking or drag-and-drop.
• Users need to select a folder, inspect the discovered directory tree, and choose which folders/files to include before upload.
• For large selections, the browser should continue processing the confirmed queue instead of requiring users to submit many small batches manually.

2. Queue management and recovery

• Failures under load may succeed after retrying, but recovery currently requires too much manual intervention.
• The upload queue should expose per-file progress and retain actionable failures.
• Users need bulk retry and bulk delete/remove for selected failed items, instead of deleting and re-uploading files one by one.
• Retry behavior should be safe and avoid creating duplicate documents.

3. Separate ingestion stages and error states

The UI should clearly distinguish failures in:

1. file transfer / upload;
2. content parsing;
3. index construction (including individual index types where applicable).

For each document, show the current stage, a useful error summary, whether retry is available, and which retry action will run. Avoid a single ambiguous “failed” state when only one downstream index failed.

4. Clarify document actions

The same or similar “Add documents” wording appears to cover different operations:

• uploading a new document to ApeRAG;
• associating an existing document with a collection.

Use distinct labels and explanatory text so users understand whether bytes will be uploaded, an existing asset will be linked, or both.

5. Knowledge graph language setting

The current “processing language” control is easily interpreted as the language of the uploaded document, while it actually controls the language of generated knowledge-graph nodes.

• Rename the field to state its effect explicitly (for example, “Knowledge graph output language”).
• Provide a sensible default and hide this control under Advanced settings for the normal flow.
• Explain how the setting behaves for bilingual or multilingual documents.
• Consider automatic/default behavior so users do not need to choose unless they have a specific graph-output requirement.

Suggested acceptance direction

• A user can select a folder, review its tree, and choose included files/folders.
• A confirmed large selection runs as a persistent, observable queue in the browser.
• Per-file state distinguishes upload, parse, and indexing stages.
• Failed items support selected/bulk retry and selected/bulk removal.
• Retry is idempotent or clearly warns about duplicate risk.
• Errors include an actionable reason and the next available action.
• “Upload new document” and “Add existing document to collection” are visibly distinct.
• Knowledge-graph language is correctly named, documented, defaulted, and placed under Advanced settings.
• Multilingual-document behavior is documented and covered by product tests.

Follow-up

Split implementation into focused child issues after product/design triage (folder selection and queueing, bulk operations, stage-specific state/error model, action naming, and graph-language settings).