How to check an Anki CSV import before adding the whole file

Write a field dictionary before exporting the spreadsheet. For each column, record what it means, whether it is required, and whether it belongs on the question, the answer, or only in supporting metadata. In the economics example, a term and its accepted definition are core content. A source page supports verification. An editing label identifies unfinished work. Combining all four into a single answer field makes the first import simpler to describe but harder to maintain later.

Now compare that dictionary with the destination note type. A similarly named field may still have a different purpose. For example, an example sentence can be a question cue in one design and an answer-side explanation in another. Draw the proposed map explicitly: source column to destination field. The official text-import manual explains the mapping controls; your dictionary explains why the choices are correct. If a destination field does not exist or should remain empty, resolve that before the full import. Do not rely on column position alone as proof of semantic compatibility.

Choose rows that expose likely edge cases, not only the shortest terms. Include a definition containing a comma, a quoted phrase, an accented character, an optional blank field, and an explanation with an intended line break if your file contains those features. Use real permitted material or harmless invented examples. The sample should test the shapes present in your file, not create new requirements that the actual collection does not have.

In the fictional sheet, one row defines a term using a short list separated by commas. Another includes quotation marks from a lecture phrase. A third has no optional example. Keep a written expectation for each resulting note. Count the intended records separately from the number of visible lines in a text editor, because formatting choices can make those counts differ. If the sample fails, preserve the failed file and a note describing the symptom. That gives you evidence for changing one formatting or mapping choice rather than repeatedly exporting the same ambiguous sheet.

For a practical edge-case ledger, write the expected number of fields beside each selected row. A definition containing a comma should still occupy its intended single field. An optional blank should not pull later source data into a different column. After the sample, check those exact expectations rather than scanning only the simplest row. This makes the test useful when a future course update adds punctuation or optional context that the first import did not contain.

Keep an untouched copy and inspect the export in a plain-text viewer as well as the spreadsheet. The spreadsheet displays interpreted cells, while the text viewer exposes separators and quoting. Look at the rows that contain punctuation and optional blanks. You do not need to memorize every formatting rule to notice an unexpected extra separator or a definition split across records. Compare each suspect row with the field dictionary you wrote.

Then reopen the file through an explicit import or parsing dialog in the spreadsheet if available, selecting the intended delimiter and encoding rather than trusting automatic detection. This is a cross-check, not proof that Anki will make the same choices. The goal is to identify whether the file itself already represents the intended table. If both viewers disagree with your expectation, fix the export before adjusting Anki. If the file is sound but the destination preview is wrong, concentrate on the destination’s separator and field mapping. Keeping these layers separate shortens diagnosis.

Check the intended note type, destination, separator, and field mapping in the current interface. Read the official manual alongside unfamiliar options, especially duplicate and update behavior. A second import can be an update or an addition depending on its settings and matching content. Decide what you intend before continuing. A mapping preview should agree with the sample worksheet, not merely display plausible words somewhere in each row.

For the economics sample, inspect the comma-containing definition and the row with the blank optional field first. If a source page appears in the answer field, stop and correct the map. If one row seems to create several entries, investigate record boundaries. If a header becomes a study question, inspect how the header was represented. After the sample import, record what was added, updated, or skipped. Those outcomes describe the operation more accurately than a generic success message. Do not repeat an uncertain import just to see whether the second attempt looks different.

Open the resulting notes and inspect actual generated fronts and backs. A field map can be technically correct while producing a poor question. In the fictional example, the term is visible on both sides because the selected template displays an explanatory field on the front. The import did not fail to read the CSV; the question design is exposing the answer. Fix the template or field usage deliberately, using a recoverable sample first.

Check the source reference and accepted answer against the original course material. A clean transfer can preserve an inaccurate definition just as efficiently as an accurate one. Ask whether a student could understand the front without remembering its spreadsheet row. For a reverse direction, test whether the definition selects a unique term. Keep the operation log until the full import has passed the same checks. If later reviews expose a systematic defect, the sample and map explain what to repair instead of forcing you to reconstruct the import choices from memory.

Expand only after the representative sample matches the intended content and behavior. Preserve the tested export settings, map, and source sheet. If the full file introduces a new row shape, add that shape to the sample rather than assuming the previous test covered it. A practical release checklist includes record scope, field meaning, required characters, generated prompts, and a recoverable original. The checklist is about the specific transfer, not a claim that every possible data problem has been ruled out.

For Elly, choose the supported CSV, TSV, or TXT workflow and inspect its own mapping rather than copying Anki assumptions. Text content does not preserve Anki templates, media, scheduling, or review history. Keep the native collection if those features matter. Evaluate a permitted source-based task such as drafting clearer questions, and compare the resulting answers with the same original material. A successful small transfer is a reason to continue checking thoughtfully, not a reason to delete the only copy whose behavior you already understand.