x

Основни глави

  1. LimeSurvey Cloud срещу LimeSurvey CE
  2. LimeSurvey Cloud - Кратко ръководство за стартиране
  3. LimeSurvey CE - Монтаж
  4. Как да проектираме добро проучване (Ръководство)
  5. Приготвяме се да започнем
  6. Конфигурация на LimeSurvey
  7. Въведение - Анкети
  8. Вижте настройките на проучването
  9. Вижте менюто за проучване
  10. Вижте структурата на проучването
  11. Въведение - Въпроси
  12. Въведение - Групи въпроси
  13. Въведение – Проучвания – Управление
  14. Опции на лентата с инструменти за проучване
  15. Многоезично проучване
  16. Кратко ръководство за стартиране - ExpressionScript
  17. Разширени функции
  18. Общи ЧЗВ
  19. Отстраняване на неизправности
  20. Заобиколни решения
  21. Разрешително
  22. Дневник на промените на версията
  23. Плъгини - Разширени
 Actions

Tab Separated Value survey structure/bg: Difference between revisions

From LimeSurvey Manual

Maren.fritz (talk | contribs)
Created page with "Един ред с въпроси на език на анкетата (напр. ще има 3 реда с въпроси, ако анкетата има 3 езика). Пре..."
Maren.fritz (talk | contribs)
Created page with "==Подвъпроси=="
Line 128: Line 128:




==Subquestions==
==Подвъпроси==





Revision as of 10:03, 23 November 2023


Импортиране и експортиране на стойности, разделени с раздели на структурата на проучването

Тази функция е предназначена да улесни използването на софтуер за електронни таблици като LibreOffice, Excel или Google Docs за създаване и редактиране на анкети. Той напълно елиминира зависимостта от SGQA кодовете.

Тази функция поддържа импортиране от ASCII или UTF-8 кодирани файлове със стойности, разделени с разделители (TSV), които имат разширение .txt.


Template:Забележка


Първи стъпки

Най-лесният начин е да вземете съществуваща анкета и да я експортирате във формат с разделени стойности. Използвайте нормалния бутон за анкета за експортиране и вместо да изберете формат .lss, изберете „Формат на разделени стойности (*.txt)“. Той ще бъде записан като файл със стойности, разделени с табулатори в правилния формат (уникод файл с разделители на табулатори), с всички правилни заглавия на колони.

Всеки софтуер за електронни таблици, който поддържа стойности, разделени с табулатори, е подходящ (напр. OpenOffice или LibreOffice). LimeSurvey игнорира всяко форматиране в електронната таблица, но не се колебайте да добавите някои, ако ви помага.

Обърнете внимание, че експортираният файл е във формат UTF-8 с маркировката за ред на байтовете (BOM) като първите три (скрити) знака. Ако щракнете два пъти върху .txt и се опитате да го отворите директно с Excel, той няма да се отвори правилно, защото Excel не осъзнава, че е във формат UTF-8. За да отворите тези файлове с Excel, първо отворете Excel, след това изберете File:Open, изберете .txt файла и кажете на Excel, че използва UTF-8 кодиране.

Ще има по един ред за всяка група, въпрос, подвъпрос и отговор. Има също редове за глобални променливи на проучването и за специфични за езика променливи на проучването. Основният език ще бъде посочен първи, последван от всички вторични езици. Така че, ако има няколко езика, цялото съдържание на основния език ще се покаже първо (напр. всички групи, въпроси, подвъпроси и отговори). Това ще бъде последвано от преведено копие за всеки вторичен език (с абсолютно същия брой и ред или редове за преведения набор).

Отношенията се предполагат по близост. И така, въпросите след група са част от тази група; подвъпросите след въпрос са част от този въпрос, а отговорите след въпрос са част от този въпрос. По този начин не е необходимо да знаете идентификаторите (gid, qid, sqid) за всякакви въпроси. Те ще бъдат изчислени автоматично при импортиране. Всъщност този формат изобщо не използва gid, qid или sqid (или SGQA кодове).


Съвети

Целта на импортирането/експортирането на стойности, разделени с раздели, е да ви позволи бързо да проектирате проучването си с помощта на електронна таблица. Очакваме, че често ще импортирате листа, ще проверявате валидността му с помощта на функцията „Показване на логиката на проучването“ и ще го тествате. Всеки път, когато го импортирате, ще получите нова анкета. Така че може да се окажете с много частично разработени проучвания, но това е добре. Просто придобийте навика да следите коя е най-новата или изтрийте старата, след като импортирате новите. Тъй като никога не използвате SGQA кодове в стойността, разделена с раздели, никога не е необходимо да се притеснявате какви кодове задава LimeSurvey за основните ключове за проучване, група, въпрос и отговор. Така че, не се колебайте да импортирате и експортирате толкова често, колкото искате.

Ето някои удобни неща, които можете да правите с този подход за създаване на инструменти:

  1. Използвайте едни и същи отговори за много въпроси. Просто копирайте редовете 'A' и поставете след всеки въпрос, който трябва да има същия набор.
  2. Използвайте едни и същи подвъпроси за много въпроси. Просто копирайте редовете 'SQ' и ги поставете след всеки въпрос, който се нуждае от него.
  3. "Зацикляне" - използвайте една и съща група много пъти'. След като групата е такава, каквато искате, копирайте я толкова пъти, колкото е необходимо. Използвайте филтриране на Excel, за да видите само редовете „G“ (за групи), и използвайте функцията за плъзгане на колони на Excel, за да актуализирате уравненията за уместност за всяка група (напр. за преброяване на населението първата уместност може да бъде „numPeople > 1“, следващото трябва да е "numPeople > 2". Функцията за плъзгане ще актуализира автоматично номера). Филтрирайте по редове „Q“ и се уверете, че всеки въпрос има уникална стойност (напр. кажете, че назовавате променливите си g1_q1, g1_q2, g1_qN, използвайте find/replace, за да конвертирате g1 в g2 втората група; g3 за третата и т.н.) .
  4. 'Пренареждане на въпроси/групи. Просто пренаредете редовете на файла с електронната таблица.
  5. Тестване на модули за проучване. За дълги проучвания може да искате да разделите тестването на модули. Просто създайте нови файлове с електронни таблици за всеки модул, като изтриете всички редове, които не ви трябват. Това избягва необходимостта от въвеждане на много данни за тестване на по-късни секции от анкетата.
  6. Тестване на задължителни въпроси. Често срещано оплакване не е необходимостта много въпроси да бъдат задължителни, а необходимостта да се изключи задължителната функция за тестване. Просто създайте основната електронна таблица със задължителни настройки на крайните желани стойности. След това, за да го тествате, просто изтрийте колоната „задължително“ и запазете тестовата версия на електронната таблица. Когато импортирате тази версия, нито един от въпросите няма да е задължителен. След като приключите с тестването, импортирайте главното копие.
  7. Настройка по подразбиране. Вместо да използвате GUI, можете да въведете желаните настройки по подразбиране в колоната по подразбиране. Това е особено полезно в случаите, когато GUI не ви позволява да въведете желаната стойност, като изрази, за да зададете стойността по подразбиране за елементи от списък (като попълване на списък от [[Участници в проучване|участник в проучване] ] атрибут).
  8. 'Превод'. Можете да създадете копия на вашата електронна таблица - по едно на език. Включете всички редове за основния език, след това ги копирайте и поставете по-долу и използвайте плъзгане, за да промените езиковото поле на целевия език. Те могат да бъдат раздадени на вашите преводачи и повторно интегрирани в един файл с електронна таблица, когато са готови.
  9. 'Групова настройка на разширени атрибути на въпроси'. Може да искате всичките ви уравнения да започнат видими (за да можете да виждате стойностите им, докато събирате данни), но след това ги скрийте всички, преди да преминете към производство. Просто филтрирайте електронната таблица по клас = 'Q' и тип въпрос = '*' (уравнение) и задайте always_hide на 1 за всеки от тези въпроси. По същия начин, да речем, след като създадете анкетата, вие решавате кои въпроси да се показват в публичната статистика. Вместо да редактирате всеки въпрос чрез GUI, филтрирайте по class = 'Q' и задайте public_statistics = 1 за всички въпроси, които трябва да се виждат в статистиката.
  10. 'Намиране и заместване'. Да речем, че решите, че трябва да промените някои фрази във всичките си въпроси, можете да използвате Excel за намиране и замяна, за да направите тези промени. По същия начин, кажете, че сте решили да направите групово преименуване на вашите променливи, намирането и замяната може да дойде на помощ. Ако имате нужда от намиране и замяна, базирано на регулярен израз, можете да изберете желаната колона, да копирате в текстов редактор, да направите своето намиране и замяна и да поставите колоната обратно в електронната таблица.
  11. ''Получаване на одобрения '. Ако правите проучване, може да имате институционален съвет за преглед, който настоява да видите текста на въпросите. Това може да е удобен начин да го споделите. По същия начин за дискусии с клиент.
  12. Екипен консенсус. Ако се опитвате да накарате група да се съгласи с формулировката или външния вид на въпрос или група, можете бързо да прототипирате/редактирате електронната таблица, да я импортирате и да покажете на екипа (чрез преглед на въпрос или група) точно какво ще видят потребителите . По този начин можете да получите одобрение от екипа, преди да напуснат стаята, вместо да се налага да документирате изисквания, да ги изграждате и да получавате одобрение на бъдещи срещи.
  13. 'Надграждане от други формати на проучване'. Ако вашата анкета е в XML, Word или друг формат, можете да създадете процес на превод, за да ги съпоставите с този формат. Въпреки че можете също да опитате да картографирате във формат .lss, предимството на този формат е, че не изисква да следите връзките на външен ключ между групи, въпроси, подвъпроси, отговори и настройки по подразбиране.


Ограничения

  1. По дизайн тази функция работи правилно само за проучвания, които използват qcode (вместо SGQA) наименуване. Тази функция предполага, че имената на променливите (идентификатори на въпроси) са уникални в цялата анкета. Имената на подвъпросите могат да се повтарят, стига да са уникални в обхвата на конкретен въпрос.


Файлов формат

Общи

Използваме един и същ набор от заглавия на колони за различни цели. Първите 14 колони служат за различни цели в зависимост от типа обект (напр. група, въпрос, отговор). Останалите колони са азбучен списък на имената на полетата на базата данни за разширени кодове на въпроси. По-долу е синтаксисът за всеки тип обект

Първите 14 колони са:

  1. id (New in 3.14.0 )
  2. related_id (New in 3.14.0 )
  3. class
  4. type/scale
  5. име
  6. уместност
  7. текст
  8. помощ
  9. език
  10. валидиране
  11. задължително
  12. друго
  13. по подразбиране
  14. същото_по подразбиране
 Hint: Колоните id и related_id се използват само за квота и не са задължителни. Ако нямате квота, можете директно да премахнете тези 2 колони.


Глобални параметри на проучването

Има един ред на параметър в таблицата с проучвания.

  1. class => 'S'
  2. name => име на полето на базата данни
  3. text => стойност


Специфични параметри за езика на проучването

Има един ред на поле за всеки език в таблицата surveys_languagessettings. Всички записи за даден език се събират, преди да се извърши вмъкването в тази таблица.

  1. class => 'SL'
  2. name => име на поле на база данни
  3. text => value
  4. language = > език


Групи

Един групов ред на език на проучването (напр. ще има 3 групови реда, ако проучването има 3 езика).

  1. id => уникален цифров идентификатор за групата, започващ с номер 1, използвайте същия идентификатор за допълнителни езици, принадлежащи на текуща група
  2. class => 'G'
  3. name => group_name -- уникалният идентификатор за групата
  4. relevance => grelevance -- уравнението за релевантност на ниво група, без фигурни скоби!N !#text => описание -- специфичното за езика описание на групата
  5. language => език -- езикът за групата (напр. 'en')


Въпроси

Един ред с въпроси на език на анкетата (напр. ще има 3 реда с въпроси, ако анкетата има 3 езика). Предполага се, че въпросите принадлежат към групата, която ги предхожда.

  1. id => уникален цифров идентификатор за въпроса, започващ с номер 1, използвайте същия идентификатор за допълнителни езици, принадлежащи към текущия въпрос
  2. class => ' Q'
  3. type/scale => type -- (обикновено една буква) тип въпрос (напр. 'M' е Multiple Choice)
  4. name => title -- the уникално име на въпрос (коренът на системата за именуване на qcode)
  5. relevance => уместност -- уравнение на уместност за въпроса
  6. text => въпрос - езикът -специфичен текст на въпроса
  7. help => помощ -- специфичният за езика помощен текст
  8. language => език -- езикът за групата (напр. 'en')
  9. validation = > preg -- незадължителните критерии за валидиране на регулярен израз за въпроса
  10. mandatory => задължително -- 'Y', ако е задължително
  11. other => other -- 'Y', ако опцията "Other" трябва да е налична (само за някои типове въпроси)
  12. default => default -- ако е зададена, тази стойност се вмъква в таблицата defaultvalues за този въпрос
  13. same_default => same_default -- 'Y' за true, в който случай всяка стойност по подразбиране, зададена за основния език, се прилага за други езици


Подвъпроси

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


Answers

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


Conditions

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