制表键分割值的调查结构

调查结构的制表键分割值得导入和导出

此功能为便于使用像 LibreOffice, Excel 或 Google Docs 电子表格软件编写和编辑调查而设计。完全排除了对 SGQA 代码得依赖。

此功能支持导入后缀是 .txt 的使用 ASCII 或 UTF-8 编码的制表符分隔值 (TSV) 文件。

通过查看 示例 进一步了解此功能。

入门指南

最简单的方式就是拿现有的调查，并导出为制表符分隔值格式。使用普通导出调查按钮，不选择 .lss 格式，而选择 "制表符分隔值格式 (*.txt)"。将会保存为拥有所有列标题的恰当格式的制表符分隔值文件 (制表符分隔代码文件)。

任何电子表格软件都能很好的支持制表符分隔值 (比如，OpenOffice 或是 LibreOffice)。LimeSurvey会忽略电子表格中的所有格式，但是如果有帮助，可以随时添加一些格式。

请注意，以 UTF-8 格式导出的文件里，字节顺序标记(BOM)作为头三个(隐藏)的字符。如果你双击 .txt 文件并尝试从 Excel 直接打开，文件不会正常打开，因为 UTF-8 的格式。要从 Excel 打开这些文件，首先打开 Excel，然后选择文件：打开，再选择，.txt 文件，并告诉 Excel 文件使用 UTF-8 编码。

每一个组，问题，子问题和答案占据一行。调查的全局变量，指定语言的变量也占据一行。主语言会在列在前面，第二语言跟在后面。如果有多种语言，基础语言的内容条目会首先显示 (比如，所有组，问题，子问题和答案)。每一个附加语言的翻译副本会紧随其后 (翻译集的数量和行的顺序要完全一致)。

关系是根据亲缘关系推断的。So, questions following a group are part of that group; subquestions following a question are part of that question, and answers following a question are part of that question. Thus, you don't need to know the IDs (gid, qid, sqid) for any questions. Those will be computed automatically upon import. In fact, this format does not use gid, qid, or sqid (or SGQA codes) at all.

提示

The goal of the Tab Separated Value import/export is to let you rapidly design your survey using a spreadsheet. We expect that you will frequently import the sheet, check its validity using the "Show Survey Logic" feature, and test it. Each time you import it, you will get a new survey. So, you might end up with many partially developed surveys, but that is fine. Just get in the habit of keeping track of which is the most recent, or delete the old one after you import the new ones. Since you never use SGQA codes in the Tab Separated Value, you never need to worry about what codes LimeSurvey assigns for the primary survey, group, question and answer keys. So, feel free to import and export as often as you like.

Here are some convenient things you can do with this approach to authoring instruments:

1. Use same Answers for many questions. Just copy the 'A' rows and paste after each question that should have the same set.
2. Use same subquestions for many questions. Just copy the 'SQ' rows and paste them after each question that needs it.
3. "Looping" - use same group many times. After the group is the way you want it, copy it as many times as needed. Use Excel filtering to view just the 'G' rows (for groups), and use the Excel column drag feature to update the relevance equations for each group (e.g., for a census, the first relevance might be "numPeople > 1", the next should be "numPeople > 2". The drag feature will auto-update the number). Filter by 'Q' rows and ensure that each question has a unique value (e.g., say you name your variables g1_q1, g1_q2, g1_qN, use find/replace to convert g1 to g2 the second group; g3 for the third, etc.).
4. Re-ordering questions/groups. Simply re-order the rows of the spreadsheet file.
5. Testing survey modules. For long surveys, you may want to break up the testing into modules. Simply create new spreadsheet files for each module, deleting any rows that you don't need. This avoids the need to enter lots of data to test later sections of the survey.
6. Testing mandatory questions. A common complaint is not the need to make many questions mandatory, but the need to turn off the mandatory feature for testing. Simply create the master spreadsheet with mandatory set to the final desired values. Then, to test it, just delete the "mandatory" column and save the test version of the spreadsheet. When you import that version, none of the questions will be mandatory. After you have finished your testing, import the master copy.
7. Setting defaults. Rather than using the GUI, you can enter any desired defaults in the default column. This is especially helpful for cases where the GUI does not let you enter the desired value, like expressions to set the default for list items (like populating a list from a survey participant attribute).
8. Translation. You can create copies of your spreadsheet - one per language. Include all the rows for the primary language, then copy and paste them below, and use drag to change the language field to the target language. These can be distributed to your translators, and re-integrated into a single spreadsheet file when they are done.
9. Bulk setting of advanced question attributes. You may want all of your equations to start visible (so you can see their values as you collect data), but then hide them all before going to production. Simply filter the spreadsheet on class = 'Q' and question type = '*' (equation), and set always_hide to 1 for each of those questions. Similarly, say after you create the survey, you decide which questions should appear in public statistics. Rather than edit each question through the GUI, filter on class = 'Q', and set public_statistics = 1 for all of the questions that should be visible in statistics.
10. Find and replace. Say you decide you need to change some phrasing across all of your questions, you can use Excel find and replace to make those changes. Similarly, say you decide to do a bulk-renaming of your variables, find and replace can come to the rescue. If you need regular-expression based find and replace, you can select the desired column, copy to a text editor, do your find and replace, and paste the column back into the spreadsheet.
11. Gaining approvals. If you are doing research, you may have an Institutional Review board who insists upon seeing the text of the questions. This may be a convenient way to share it.  Similarly for discussions with a client.
12. Team consensus. If you are trying to get a group to agree upon the wording or appearance of a question or group, you can rapidly prototype / edit the spreadsheet, import it, and show the team (via question or group preview) exactly what the users will see.  That way you can get approval from the team before they leave the room rather than having to document requirements, build them, and get approval at future meetings.
13. Upgrading from other survey formats. If your survey is in XML, Word, or other format, you can create a translation process to map them to this format. Although you could also try mapping to the .lss format, the advantage of this format is that it doesn't require you to keep track of foreign key relationships between groups, questions, subquestions, answers, and defaults.

Limitations

1. By design, this feature only works properly for surveys that use qcode (rather than SGQA) naming. This feature assumes that variable names (question identifiers) are unique throughout the survey. Subquestion names can be repeated, as long as they are unique within the scope of a particular question.

常规

We use the same set of column headings for multiple purposes. The first 14 columns serve different purposes depending upon the type of entity (e.g., group, question, answer). The remaining columns are an alphabetical list of the database field names for the advanced question codes. Below is the syntax for each entity type

The first 14 columns are:

1. id ^{(New in 3.14.0 )}
2. related_id ^{(New in 3.14.0 )}
3. class
4. type/scale
5. name
6. relevance
7. text
8. help
9. language
10. validation
11. mandatory
12. other
13. default
14. same_default

 Hint: Columns id and related_id are used only for quota and are optional. If you don't have quota, you can directly remove this 2 columns.

调查的全局参数

There is one row per parameter in the surveys table.

1. class => 'S'
2. name => database field name
3. text => value

调查特殊语言的参数

There is one row per field per language in the surveys_languagesettings table. All entries for a given language are collected before doing the insert into that table.

1. class => 'SL'
2. name => database field name
3. text => value
4. language => language

组

One group row per survey language (e.g., there would be 3 group rows if survey has 3 languages).

1. id => unique numeric identifier for the group, starting with number 1, use the same ID for additional languages belonging to current group
2. class => 'G'
3. name => group_name -- the unique identifier for the group
4. relevance => grelevance -- the group-level relevance equation, without curly braces
5. text => description -- the language-specific description of the group
6. language => language -- the language for the group (e.g., 'en')

问题

One question row per survey language (e.g., there would be 3 question rows if survey has 3 languages). Questions are assumed to belong to the group that precedes them.

1. id => unique numeric identifier for the question, starting with number 1, use the same ID for additional languages belonging to current question
2. class => 'Q'
3. type/scale => type -- the (usually one letter) question type (e.g., 'M' is Multiple Choice)
4. name => title -- the unique question name (the root of the qcode naming system)
5. relevance => relevance -- the relevance equation for the question
6. text => question -- the language-specific text of the question
7. help => help -- the language-specific help text
8. language => language -- the language for the group (e.g., 'en')
9. validation => preg -- the optional regular expression validation criteria for the question
10. mandatory => mandatory -- 'Y' if mandatory
11. other => other -- 'Y' if the "Other" option should be available (only for some question types)
12. default => default -- if set, this value is inserted into the defaultvalues table for this question
13. same_default => same_default -- 'Y' for true, in which case any defaultvalue set for primary language applies to other languages

子问题

One subquestion row per survey language. Subquestions are assumed to belong to the question that precedes them.

1. id => same unique numeric identifier which is used for the questions. Subquestions should use next available value, question and subquestion IDs should be different (e.g. use ID 1 for question and IDs 2, 3 and 4 for subquestions belonging to question 1, next question ID should be 5 and so on). Use the same subquestion ID for additional languages belonging to current subquestions.
2. class => 'SQ'
3. type/scale => scale_id -- 0 or 1, depending upon question type (e.g. array text will have two scales)
4. name => title -- the "name" of the subquestion, e.g. the one used for exclude_all_others
5. relevance => relevance -- (Future) to support subquestion-level relevance
6. text => question -- the language-specific text of the subquestion
7. help => help -- (Future) to support subquestion-level help
8. language => language -- the language for the subquestion
9. validation => preg -- (Future) to support subquestion-level regular expression validation (e.g. for address parts)
10. mandatory => mandatory -- (Future) to support subquestion-level mandatory (e.g. make only a few subquestions mandatory)
11. default => default -- if set, then this is the default value for the subquestion (inserted into defaultvalues table)
12. same_default => same_default -- if set, then the default for the primary language is  used for all other languages

答案

One answer row per survey language (e.g., there would be 3 answer rows if survey has 3 languages). Answers are assumed to belong to the question that precedes them, and be in the desired sort order.

1. id => use the same ID as the ID of the question it belongs to
2. class => 'A'
3. type/scale => scale_id -- 0 or 1 (e.g. for dual-scale)
4. name => code -- the unique answer identifier
5. relevance => assessment_value -- if using assessment option, this is the assessment value for the answer
6. text => answer -- the language-specific text of the answer
7. language => language -- the language for this answer (e.g. 'en')

Assessments

One assessment row per survey language (e.g., there would be 3 assessment rows if survey has 3 languages). Assessments are written at the end of file.

1. id => unique numeric identifier for the assessment, starting with number 1, use the same ID for additional languages belonging to current assessment
2. related_id => id of group to which current assessment belongs to
3. class => 'AS'
4. type/scale => assessment scope: T-Total, G-group
5. name => name
6. text => message
7. min_num_value => Minimum
8. max_num_value => Maximum
9. language => language -- the language for this answer (e.g. 'en')

Quotas

One row per quota. Quotas are written at the end of file.

1. id => unique numeric identifier for the quota, starting with number 1
2. class => 'QTA'
3. name => quota name
4. mandatory => limit
5. other => quota action
6. default => active
7. same_default => autoload URL

Quota language settings

One quota row per survey language. Quota language settings are assumed to belong to the quota that precedes them.

1. id => unique numeric identifier for the quota language settings, starting with number 1. Each row for different survey languages should have different IDs
2. related_id => quota id of quota to which this setting belongs to
3. class => 'QTALS'
4. relevance => message
5. text => URL
6. help => URL description
7. language => language -- the language for this quota (e.g. 'en')

Quota members

One row per quota member, no language dependent. Quota member row should be placed immediately after question it relates to. Quota members are assumed to belong to the question that precedes them.

1. id => unique numeric identifier for the quota members, starting with number 1
2. related_id => quota id of quota to which this member belongs to
3. class => 'QTAM'
4. name => answer code

条件

One row per condition, no language dependent. Condition row should be placed immediately after question it relates to. Conditions are assumed to belong to the question that precedes them.

1. id => unique numeric identifier for the condition, starting with number 1.
2. related_id => question id of related question, if applicable
3. class => 'C'
4. type/scale => scenario
5. name => answer field name
6. relevance => comparison operator
7. text => expected answer