1 Internationalization for snips 1.1 The problem I don't mind writing stuff in english, but since my native language is german I also like to write in german from time to time. For my personal SnipSnap running at home I have the problem that I have friends that - don't speak english, and some that - don't speak german. 1.1 Solutions Now, what should I do if I want to, say, post some stories and images from my last vacation on my SnipSnap? I could: - Simply add german and english texts in all snips, letting the reader sort it out. - Set up two instances of SnipSnap, one for german native speakers and one with english as main language (I wouldn't even dream of wanting to synchronize these). - Use a naming convention for snips, like <foo>-de and <foo>-en (similar to Java resource bundles). SnipSnap already does this for comments. - Use namespaces for i18n, see [phobia]s note about [special namespaces] in this context. - Try to use labels to achieve this, maybe in combination with namespaces. - Provide "inline" snip support for i18n, maybe with use of macros. I'll quickly sketch some of the pros/cons (in my opinion) below. 1 Namespaces I think using namespaces would provide the most powerful solution here. Using something like "/mysnip" for the default language and "/mysnip/i18n/de" for the german version would be fine. That is if I wanted to use SnipSnap for something where the focus also lies on internationalization. For use in a fast changing environment where users add ideas, post comments, etc. this is probably overkill and hard to maintain. The advantage on the other hand is a clear separation and I could always "extract" one language part, automatically check what still needs to be translated, maybe even employ tools like {link:Babel Fish|http://babelfish.altavista.com/} to automatically translate untranslated stuff. Handling of requests wouldn't be simple anymore though, if a user requests "mysnip" he should get "mysnip/i18n/de" automatically if his language preference is german. A link at the top of the page should indicate that there are also other language versions available and last but not least input should also provide support for multiple languages. => Sounds like a fairly complicated solution. 1 Naming pattern for snips A simple straightforward solution that could be implemented similar to comments. The pros and cons are probably the same as for the namespaces solution sketched above, while it tastes a bit more like a "hack". :-) 1 Inline internationalization That would be a very straightforward and simple way to get i18n. Consider the following macros: {code} \{i18n\} \{lang:de\} Deutscher Teil. \{lang:de\} \{lang:en\} English part. \{lang:en\} \{i18n\} {code} Like this I could enter everything in one place and still render the preferred language for a user. Everything enclosed in a \{i18n\} block only gets rendered once, namely in the best suited language. This way I could also mix multi-language stuff in one snip. 1 Other solutions? Any comments, ideas?!? 2004-09-05 08:59:59.494 2004-09-05 08:59:23.269 I prefer your latter approach. The macro should even be possible today, although I'm not sure I've seen any examples of macros that "nest" like that. Perhaps the nesting isn't even necessary. How about just the "language" macro, with an optional parameter that specifies whether the content should be always renders, rendered only if it matches the user locale, or rendered if no other content in this snip matches the user locale? That last scenario might be tricky to implement. 2004-09-05 22:02:50.768 2004-09-05 22:02:50.239 I suggest that macro following: {code} {language:default=en} de: Deutscher Teil. en: English part. cn: 中文 {language} {code} 2004-09-06 12:06:42.166 2004-09-06 12:03:51.173 [@phobia:|phobia] The reason I was thinking about a nested macro is that you need to be able to decide which translations belong to each other. I don't know if there are any implementation issues involved in retrieving the context block (i18n in the example) from the language macro, but when I wrote this I was just dumping an idea without actually thinking about the implementation. Also I don't know if it's really necessary to use a fallback language, but if I remember correctly, the client sends a block of languages in order of preference and then, well, the information would be needed to provide a best effort translation. [@tigerf:|tigerf] That would be even simpler to implement. I would omit the default language though, since there's a default for SnipSnap and there's the preferences from the client. Yet another default would probably be too much and trigger too seldom. More interesting to me would be how you go about writing larger blocks of text. I see that the macro would be handy to write a single sentence. But how about complex structured text? (That's why I thought about using a nested macro since the user is already familiar with the concept, even though probably not if they are used in context.) ---- The problem with translation ~~whole~~ snips however remains. Wouldn't it be simpler to have different snips for the translation. E.g. I was just thinking how this very snip looked if I had written it in more than one language... Maybe SnipSnap should even provide several ways to achieve internationalization, letting the user choose what suits her best for a given purpose. 2004-09-06 21:23:42.536 2004-09-06 21:23:40.567 I don't like using namespaces or multiple snips (clutters the snipspace) but understand the compulsion to "break up" the content. Maybe content via attachments? They could have locales associated with them, or be included within macros as we've discussed via include macros. But then you lose the abilities of snips (revision history, etc)... Every time I ponder it, I come back to believing that all the content should be in the same snip... it is, after all, the same content, just "rendered" differently. 2004-09-07 16:26:06.497 2004-09-07 16:26:05.445 To include [essmann/ideas/i18n] into [SnipSnap] is for me too much of an adempt to create a [Eierlegende Woll-Milch-Sau]. A translation of a snip is a further dimension which should not be modelled using one of the existing means like different snips and or namespaces. I would also prefer the macro in a single snip solution. Also in a wiki with even moderate changes in content the snips are always a moving target so that translation would never be able follow the originial content. Because of this I personally would consider using i18n only for rare use cases. For such an easy to implement and straight forward approach will be the most effective. 2004-09-07 20:01:18.873 2004-09-07 20:01:15.239 Hi, I created i18n macro. It can be downloaded from {link:my site|http://www.physalis.net/ss/space/i18n-plugin-en}. Although I noticed this snip today, my i18n macro looks like rather tigerf's idea which suits short text. I'm using this in my site to switch menu text and snip links (one linked to English page and one to Japanese page). 2005-05-02 11:02:41.679 2005-05-02 11:02:38.486