From: Demian K. <dem...@vi...> - 2013-02-08 15:14:23
|
It is an interesting idea to tie the translation strings to the theme system. I can see some advantages to that, though it would also add some complexity (there would be a lot more data to cache, since every combination of theme options would have to be cached separately). I'll put this on the agenda to discuss on the next developers call. For now, it might be easier to simply use unique strings in different themes where there are reasons to have different text (as we already do in some places -- e.g. having _short versions of some strings for use in the mobile theme). That allows you to get the text you need in your themes, but you only have to manage one set of language files (or two sets, if you use the local/languages directory to override defaults in the languages base directory). As far as needing language knowledge to work on the language files, that's not a strict requirement -- I've done all the integration work so far, and I only speak English (a fact which does not make me proud... but I haven't managed to change it). It's relatively easy to rearrange the language files to be consistent with one another without understanding the actual translations that they contain. For example, if we start using strings with tokens as discussed earlier ("%start% - %end% of %total%", etc.) it isn't hard to build these strings from the existing fragments in the existing files. In some cases, they may not be totally correct, but at least the language files will reflect what VuFind is currently doing, and then native speakers can review them and make improvements. To answer your specific questions: - I don't have a strong opinion about whether or not every string needs to be converted to be something abstract like add_comment_fail_blank. It might be a good idea for consistency, but it might also make the templates harder to read and use. I think it's only absolutely essential in cases where the string might be ambiguous -- particularly single-word strings like "Title" which could mean a number of different things. For very long phrases where it is unlikely that they could have different meanings in different contexts, it might be okay to leave them in their raw English form. - Right now, the fact translations are mixed into the language files with everything else -- for example, all of the values found in the Format facet (based on the default format.bsh script) can be found in en.ini, etc. I just think we should group these with a prefix and check for inconsistent use of the existing terms to prevent confusion. On a related note, the values in the language facet should be added -- currently it is not possible to translate language names, but this would be useful (as was mentioned near the beginning of this thread). Hopefully that's somewhat helpful, but let me know if anything remains unclear. - Demian ________________________________________ From: Oliver Schihin [oli...@un...] Sent: Friday, February 08, 2013 9:38 AM To: Demian Katz Cc: Katharina Wolkwitz; vuf...@li... Subject: Re: [VuFind-General] Facet-translation problem after upgrade to 1.4 Hi I've been thinking about the translation mechanisms in vufind2 lately. We do have a multilingual installation (ger/fre/eng/ita) and we are very glad that so much comes bundled with the core. Still, we will have to be able to overwrite translations and language ini-files per theme. That said, I do volunteer, as reluctantly as Kate, to look into the matter. And I do neither speak Euskara nor Chinese nor do we need these languages. But to have VuFind translated and usable in so many languages is a great asset. We are not using bluetheme, but will take some profit out of clearer codes in the *.ini-Files Questions: * Looking at the ini-Files in the language directory: Is the idea to apply a scheme like the one used for codes after 'add_comment_fail_blank'? * Where are the facet-translation-fields, the /web/lang-Directory? Not yet ported to VF2? So, for the matter, I do not really know how to start, and where, but if I can help or if there are discussions around, you can contact. Oliver -------- Original-Nachricht -------- Betreff: Re: [VuFind-General] Facet-translation problem after upgrade to 1.4 Von: Demian Katz <dem...@vi...> An: Katharina Wolkwitz <wol...@fh...>, vuf...@li... <vuf...@li...> Datum: 08.02.2013 13:30 > Don't worry, I understand that it's a big job! If it weren't, I would just do it > myself -- I really hate saying "no" to a reasonable request. > > But certainly, if nothing else, it is helpful to have somebody paying attention to the > issue. Even if we're just reminded that it exists every few months, that helps improve > the odds of someone being around who is willing and able to take on the challenge. > > Regarding the sorting issue, I think we may have discussed this before, but I'll risk > repeating myself to be on the safe side. The current sort order is a side effect of > the tools I use. jEdit is the best text editor I've found for managing the language > files, since it has good Unicode support. jEdit includes a plugin that sorts text -- > but it sorts it in pure ASCII order, putting uppercase before lowercase. I can't find > a simple, convenient way within the editor to sort in a more human-friendly way, so I > do this since ASCII-sorted is better than not-sorted-at-all, especially since having > them sorted this way allows me to use other jEdit tools to automatically remove > duplicate lines, etc. Obviously, if I put some time into it, I could probably find a > better way with different tools (or maybe even just different jEdit plugins); but this > has been an easy way for me to manage the language files, so I've stuck with it. If > somebody knows of a better workflow or better tools for doing the job, I'll be happy to > adapt -- I just haven't found a solution quickly and haven't had time to do detailed > research. > > Also, while I agree that sorting in a more human-readable way would make the language > files a bit easier to read and understand, I don't know that it really helps too much > with the problem of avoiding duplicate entries. For most texts that you would want to > add to the file, you need to do full-text searches of a variety of keywords to make > sure that there isn't already a string there that mentions the concept you are trying > to add -- there are always several ways to express a particular concept, and the key > word(s) aren't always at the beginning of the string, so browsing alphabetically > usually isn't the best way. (At least, that's the way I've been doing this -- and > that's why the weird sorting hasn't really been an inconvenience for me when managing > the files). > > - Demian ________________________________________ From: Katharina Wolkwitz > [wol...@fh...] Sent: Friday, February 08, 2013 3:25 AM To: > vuf...@li... Subject: Re: [VuFind-General] Facet-translation > problem after upgrade to 1.4 > > Hi Demian, > > I've found the pages on translation in Vufind 2.0 after writing my last email, so I > have to apologise for calling out so loudly for a revamp, that had indeed already taken > place. > > But even as I can understand your need for a shepherd or sherpherdess, I'm afraid that > job is way to large and complicated for me to take on. I could volunteer for a job as > parttime sheepdog though, if such a position was on offer. ;-) > > Offering as my first wooof: I've found that the example en.ini-file listed on the > wiki-page for translation in Vufind 2.0 > http://vufind.git.sourceforge.net/git/gitweb.cgi?p=vufind/vufind;a=blob;f=languages/en.ini;hb=HEAD > > is still not sorted strictly alphabetically but listing Uppercase before lower > case, thus making it possibe to have in total three places to find a phrase beginning > with the word "and" (AND, And, and), which is quite a lot if one's not sure of the > correct "spelling" (???). If one now adds the possibility of spaces, underscores, > hyphens and slashes to the mix I get the feeling, it's easier to create a duplicate > entry than finding the one that already exists. > > I'm not really sure how to avoid the problem of creating unwanted duplicate entries in > the language.ini-files, but I'd think sorting them case-insensitive and thus more > alphabetically would help. > > Kate > > Am 07.02.2013 17:47 schrieb Demian Katz: >>> Btw. are there translation-lists of language-"names" for the most-common (from my >>> point of view) languages (e.g. english, german, french, spanish) as an "add-on" to >>> the respective language .ini-files (en.ini, de.ini, fr.ini, es.ini)? >> >> I'm sure these can be found somewhere if you look hard enough, but I don't have a >> reference available off the top of my head. >> >>> Is the translation-system getting a revamp in Vufind 2.0 like the programming is? I >>> think something like a having a good look at what's there and giving it a good stir >>> might be a good idea... ;-) >> >> I've already revamped the code for VuFind 2.0's translation system. It has a couple >> of important new features: >> >> 1.) A flexible mechanism for including tokens within messages... so you can >> translate a string like "<a href='%url%'>Export to %target%</a>." (In this example, >> %url% and %target% would be the same in all language files, as would the HTML markup, >> but the rest could be changed as needed). >> >> 2.) The ability to specify a default text to use if no match is found in the language >> files. This makes it possible for us to add more prefixes to strings within the >> language files to reduce ambiguity and improve organization without worrying about >> users seeing bizarre strings on screen if the language files are incomplete. For >> example, rather than having strings like "Book" in the file, we could use >> "facet_format_Book" and default to "Book" as the text if no translation for >> "facet_format_Book" is found. >> >> So that's the good news. >> >> The bad news is that in order to take full advantage of these new features, somebody >> needs to do a deep analysis of the text in our language files and how/where that text >> is used in our templates. We need to do a lot of cleanup -- being consistent about >> putting punctuation in the language strings in the file rather than hard-coding it in >> the templates, prefixing facet values as mentioned above, putting together chunked >> text into strings with tokens to allow better rearrangement in languages with >> different grammatical structures, etc. Unfortunately, this is a huge project that I >> don't have time for -- I think good translation support is important, but since my >> own institution only offers the interface in one language, it's hard to justify >> spending weeks or months on this kind of a revamp. >> >> I think in order to happen, somebody needs to volunteer to shepherd the project >> through. I'm definitely happy to support and advise such an effort; I just can't >> commit to doing it myself. Anybody interested? >> >> - Demian >> > > > -- Mit freundlichen Grüßen > > Katharina Wolkwitz > > Fachhochschule Südwestfalen Hochschulbibliothek Haldener Straße 182 58095 Hagen Tel.: > 02331/9330-607 FAX: 02331/9330-608 > > ------------------------------------------------------------------------------ Free > Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March > 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ VuFind-General mailing list > VuF...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-general > > ------------------------------------------------------------------------------ Free > Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March > 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ VuFind-General mailing list > VuF...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-general . > |