Answers.Body: <p>In addition to the answers of Xavier and Mathieu I would like to add some non-technical aspects for your consideration.</p>
  
  <p>IMHO a multilanguage set up considerably raises complexity in a lot of ways for users and admins alike. Think auomated emails, online forms or extensions just to name a few. All issues arising from those can probably be dealt with but it is definitely time consuming and not fun at all (also given the lack of documentation)!</p>
  
  <p>In short, unless it is absolutely necessary I would recommend to stick to a single-language set up. </p>
  
  <p>PS: Even eithout multi-language you can use CiviCRM's user interface in various languages - however some elements (such as option groups, contribution status...) wont be translated...</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-06T13:09:52.620Z
Answers.LastActivityDate: 2016-06-06T13:09:52.620Z
Answers.UserDisplayName: Fabian
Answers.Body: <p>So the problem is that each new language is stored as a separate column for each translated field (eg title, body...), so the more fields that are translated and the more new language you add, the sooner you will hit a limit of mysql on how many columns can be set. As for the exact number, it depends as well on the type of content you store, mysql has a longer explanation, but 2 or 3 is what I've tested without reaching that limit:
  <a href="http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html</a></p>
  
  <p>Other than that, works pretty ok, but keep in mind that because the structure of the database is changed, it becomes impossible to revert to a single language version.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-25T14:56:02.190Z
Answers.LastActivityDate: 2016-02-25T14:56:02.190Z
Answers.UserDisplayName: Xavier
Answers.Body: <p>I did some more testing, and managed to get it up to 8 languages, if using the Barracuda file type in MySQL. In the default mode (Antelope), I could only enable 6 languages.</p>
  
  <p>The main issue is the "civicrm_event" table, which has a lot of text fields.</p>
  
  <p>WARNING: this has not been extensively tested. Use at your own risk.</p>
  
  <p>To try it:</p>
  
  <p>In the MySQL configuration (ex: /etc/mysql/conf.d/civicrm.cnf), add:</p>
  
  <pre><code>innodb_file_per_table = 1
  innodb_file_format = Barracuda
  </code></pre>
  
  <p>(then restart MySQL)</p>
  
  <p>Then alter the civicrm_event table to use dynamic allocation for all varchar/text columns:</p>
  
  <pre><code>drush civicrm-sql-cli
  
  alter table civicrm_event ROW_FORMAT=DYNAMIC;
  </code></pre>
  
  <p>I documented this in: <a href="https://issues.civicrm.org/jira/browse/CRM-17827" rel="nofollow">CRM17827</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-03T05:15:07.487Z
Answers.LastActivityDate: 2016-06-03T05:15:07.487Z
Answers.UserDisplayName: bgm
Body: <p>I am considering enabling multiple languages (in CiviCRM 4.6.12 with Drupal) and would like to hear from those of you who've done so about your experiences. Specifically, how many languages are you using, and have you observed any database problems as a result?</p>
  
  <p>I read in <a href="https://civicrm.stackexchange.com/questions/4329/multilingual-support">a discussion here</a> that enabling more than 2-3 languages can lead to database problems. This <a href="https://london2013.civicrm.org/sessions/parlez-vous-civicrm-internationalisation-and-so-many-other-languages" rel="nofollow noreferrer">presentation from CiviCon 2013</a> gives the number as 3-4. Has anyone successfully used more than 4? </p>
  
  <p>Are there other pitfalls of multilingual support I should be aware of, even if I stick to only 2-3 languages?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-25T18:39:04.070Z
Comments.Text: How many languages are you thinking of? More than 4 could be 5, or 100 ;-)
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-25T19:21:09.623Z
Comments.Text: I'm mainly curious to see what's been tried, but let's say 10-15. :)
Comments.UserDisplayName: juniperphoenix
Tags: <i18n>
Title: Multilingual support and database issues -- how many languages?
ThreadText: # Multilingual support and database issues -- how many languages?
  
  (Asked by: username_0 on 2016-02-25)
  
  I am considering enabling multiple languages (in CiviCRM 4.6.12 with Drupal) and would like to hear from those of you who've done so about your experiences. Specifically, how many languages are you using, and have you observed any database problems as a result?
  
  I read in [a discussion here](https://civicrm.stackexchange.com/questions/4329/multilingual-support) that enabling more than 2-3 languages can lead to database problems. This [presentation from CiviCon 2013](https://london2013.civicrm.org/sessions/parlez-vous-civicrm-internationalisation-and-so-many-other-languages) gives the number as 3-4. Has anyone successfully used more than 4?
  
  Are there other pitfalls of multilingual support I should be aware of, even if I stick to only 2-3 languages?
  
  **Tags:** i18n
  
  > **Comments:**
  > **username_1**: How many languages are you thinking of? More than 4 could be 5, or 100 ;-)  
  > **username_0**: I'm mainly curious to see what's been tried, but let's say 10-15. :)  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_2 on 2016-06-06. Score: 1
  
  In addition to the answers of username_3 and Mathieu I would like to add some non-technical aspects for your consideration.
  
  IMHO a multilanguage set up considerably raises complexity in a lot of ways for users and admins alike. Think auomated emails, online forms or extensions just to name a few. All issues arising from those can probably be dealt with but it is definitely time consuming and not fun at all (also given the lack of documentation)!
  
  In short, unless it is absolutely necessary I would recommend to stick to a single-language set up.
  
  PS: Even eithout multi-language you can use CiviCRM's user interface in various languages - however some elements (such as option groups, contribution status...) wont be translated...
  
  
  ---
  
  ### Answer by username_3 on 2016-02-25. Score: 1
  
  So the problem is that each new language is stored as a separate column for each translated field (eg title, body...), so the more fields that are translated and the more new language you add, the sooner you will hit a limit of mysql on how many columns can be set. As for the exact number, it depends as well on the type of content you store, mysql has a longer explanation, but 2 or 3 is what I've tested without reaching that limit:
  <http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html>
  
  Other than that, works pretty ok, but keep in mind that because the structure of the database is changed, it becomes impossible to revert to a single language version.
  
  
  ---
  
  ### Answer by username_4 on 2016-06-03. Score: 0
  
  I did some more testing, and managed to get it up to 8 languages, if using the Barracuda file type in MySQL. In the default mode (Antelope), I could only enable 6 languages.
  
  The main issue is the "civicrm\_event" table, which has a lot of text fields.
  
  WARNING: this has not been extensively tested. Use at your own risk.
  
  To try it:
  
  In the MySQL configuration (ex: /etc/mysql/conf.d/civicrm.cnf), add:
  
  ```
  innodb_file_per_table = 1
  innodb_file_format = Barracuda
  
  ```
  
  (then restart MySQL)
  
  Then alter the civicrm\_event table to use dynamic allocation for all varchar/text columns:
  
  ```
  drush civicrm-sql-cli
  
  alter table civicrm_event ROW_FORMAT=DYNAMIC;
  
  ```
  
  I documented this in: [CRM17827](https://issues.civicrm.org/jira/browse/CRM-17827)
  
  
  ---
  
  