Jump to content

yellowled

Members
  • Posts

    284
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by yellowled

  1. I tend to not do mockups at all, I just start by designing an HTML prototype in the browser. This probably why I prefer systems like PW which don't dictate any markup at all — makes it much easier to transfer the HTML prototype into templates.

    If I do mockups, I usually use plain old pen and paper for a really quick scribble. It's just way quicker if you're not used to doing it in a graphics app.

  2. Nothing to be sorry about, I just wanted to explain why this is not something that can be fixed within a few days. There's a lot of good ideas in another thread to maybe make translations easier to handle in the future, most of which are directly related to this very discussion. I'm sorry I can not offer a "perfect" German translation as of now, but be assured this will be maintained and developed further.

  3. First of all: Fancybox 2 is a rewrite, Fancybox 1 is still around (but unmaintained, apparently). Fancybox 2 is free for personal or non-profit use. It now has a commercial license of 15€/19$ for a single domain, 69€/89$ for multiple domains.

    It's not that I wouldn't pay for a good lightbox script, but some of my clients won't, so I needed a "free as in free beer" alternative anyway.

  4. I will spend my afternoon building a gallery including lightbox support. Pretty boring stuff, actually.

    So to accompany this with a Pub thread: what's everyone's favorite lightbox script and why? I used to go with Fancybox for pretty much everything for a long time, but since they switched the license for fancybox2, I have been using Colorbox a lot.

  5. Ralf, I don't mean to be rude. But most of your suggestions so far are, as MadeMyDay noted, purely cosmetic. You also come across pretty pushy on a subject most people here don't consider that urgent. I understand where you're coming from and why you would like it to be translated 100%, but obviously, the translation hasn't kept you from using PW, so it can't be that bad.

    So before you suggest that something might be a bug (which clearly isn't, it's merely a not perfect part of PW), I suggest you consider the fact that what you're doing here is critisizing work people do in their free time. You might also want to note that while the German translation might not be 100% complete, it is pretty close to that. And finally, please accept that while PW is great in many areas, it is still in development in others.

    Internationalization (i.e. making a software translatable in other languages) is hard. It's not something developers like to implement because it's fun. It is not fun, it takes a lot of planning and thinking ahead. It is also not a crucial part of any software. I realize you think it is, but I assure you there are more important parts of PW to be improved and developed.

  6. First of all, Pete is completely right: translation/internationalization is hard. It's tedious, nobody likes to do it, it sucks. :lol:

    Are you thinking of something like a "find translatable files" tool that's built in?

    I think I already mentioned that I'm involved in another open source project, which has very few developers, so we have to rely on non-developer help. Most of that is done in the translation area. From that experience, I would recommend to make creating and maintaining translations as easy as possible, even for "normal" users. It will help spread PW even more if it is properly translated in as many languages as possible.

    Personally, I would be fine with the grep command. However, a lot of people have to work on servers or in small hosting plans which don't offer shell access. For those people, some kind of non-shell solution would be helpful. Doesn't have to be integrated in PW or the admin backend at all, it could as well be an extra PHP script or something. Just a solution to get the translatable files without shell access, maybe marking "new" translatable files, if that's possible.

    I have to agree that PW's internationalization already is pretty comfortable. I also think it's perfectly acceptable to have some parts which are not (yet) translated. In my opinion, you can not use most open source software without knowing at least some English. Seems impossible.

    But once PW starts to attract the "non-technical users" (which, as far as I can tell, it already is), there will be more people wanting to use it which barely understand English. Or not at all. Trust me, it will not keep them from wanting to use it anyway. You'll very soon get inquiries whether we could have a subforum in Spanish or something. ;)

    • Like 3
  7. First of all, I push quite a number of new and revised translations to GitHub today. Haven't checked for new translations yet since I did those on a server without ssh access, which makes it hard to check for new translatable files.

    Second, I admit I only skimmed those screenshots, but I am pretty sure most of this stuff is properly translated in the standard admin theme. I never use anything else, so I can't really tell whether it's related to the admin theme. You should check with the standard admin theme. Also always consider that there still are quite a number of parts of PW which are not translatable at all.

    • Like 2
  8. I could maintain a default translation pack on GitHub, which already has all the files in it (empty, ready for edits).

    While I do think this would help, a more comfortable inteface for editing and maintaining language packs in the backend might help to get PW translated to even more languages. I also assumed that the moved translations would be an exception. :) Generelly, I think PW will benefit from anything which doesn't add to your workload, so maybe the master translation isn't really necessary if it's a lot of work.

    This one may be easy for us to accomplish if we just say that a translation with nothing but a period "." in it might be considered intentionally empty, or something like that. Then I can add a bit of code to detect it and have the parser fall back to the default text when it sees that.

    Sounds good to me. :)

    Upgrades shouldn't touch your translations. This is one of the reasons why translations are kept as part of your /site/ structure rather than your /wire/ structure.

    Hm. Maybe something different went wrong in my case. Can't really reproduce it, so I was probably wrong about it. Sorry for making a fuzz about it.

    The real "issue" at hand is, as soma points out, that once a translation hits a certain level of completion, it's very hard to keep it up to date on a regular basis. This may be my Kraut efficiency talking, but while I think it's great to have many translations, it doesn't really help if they're incomplete or outdated. In most open source projects, translations are done by non-coders, which is a great way for them to "give something back", also taking some work off of the developers. So translating should be as easy as possible. (It's not that I am lazy or something. ;))

    1. Being able to export changes would also be nice. No more having to look for that one folder in assets/files. :)
    2. Yes, English would be the fallback. Some technical terms are pretty universal or at least acceptable in other languages.
    3. You're probably right, the "contribute when you have the time" factor is crucial for most open source projects.
    4. You're probably right. Moreover, maintaining multiple versions is pretty insane as well. Then again, using a GitHub repo, it's not that much work.
    5. I think it would be good to indicate and/or separate "system" and "user" translations, I'm just not sure it makes sense from a technical point of view.
  9. I'd like to share and discuss some things I've come across maintaining the German translation.

    1. Ryan has outlined a way to get the translatable files in PW: http://processwire.c...__20#entry11232 — while this does work, it's not very comfortable. It would make translations much easier if there was a way to get those in the backend, as well as maybe detect which translatable files are new or abandoned. For instance, I think InputfieldRadiobuttons just got moved to a separate directory, making the previous translation file uneditable.
    2. I think it would also be good to have different "states" for empty fields in translations. As of now, "empty" could mean "not translated yet" as well as "doesn't require translation, can fall back to English value". Updating a translation would be easier if one could just skip the values which don't need to be translated, but obviously, this would be nice to have. It's definitely not a must-have.
    3. Which brings up the question as to when to actually update a translation. Obviously, doing that constantly as changes are committed to GitHub is insane. So it would make sense to update translations based on a release. As far as I have followed PW development, there is no alpha/beta stage, right? It would be nice to have some phase before a release where nothing new is added so translations could be updated to be ready along with a new release.
    4. Another thought: Let's say I install a translation for PW 2.3 in a PW 2.2 installation (or vice versa). Are there going to be any "side effects"? Should we maintain versions of the translations for specific PW releases?
    5. Most pressing issue in my humble opinion: currently (as far as I can see, please correct me if I'm wrong), there's no "protection" for additional translations added. Let's say I install a translation, then I add some translations of my own, maybe related to the templates of the site or some help texts in the descriptions of fields. Then I update PW and the updated installation. In that case, all my additional translations will be overwritten by the updated translation, right? If so, there should at least be a way to backup the additional translations, although I figure this could be hard to implement given the JSON format of the translations.

    Oh boy. Sorry for rambling here, I hope this makes some sense. :)

    • Like 3
  10. Exactly. There are some words which (at least in my opinion) are

    a. very "established" in German, althought they are actually English

    b. don't really have a proper and common German translation

    Some of those might be "translated" anyway because they are spelled differently in German, though. For instance, most English people tend to write "email", the proper German form is "E-Mail".

    • Like 1
  11. Ok it would be right that for the word "Admin" we didn´t need a "better" Translation (because we have enough "Denglisch" in our Language)

    First of all (I don't think anybody mentioned this already), a complete translation is not even possible as of now because some parts of PW and some modules are not translatable.

    Personally, I don't mind some English words in the admin backend. If there is no proper German translation, I'd rather have a well-known English term than a bad German translation just for the sake of translating, because a bad translation can be just as confusing as an English word. For example, there is no sensible German expression for „E-Mail“. (I'm not 100% sure, but I think that one actually is translated technically because the german spelling is a little different.)

    Translating everything just to get rid of the "x blanks" hints is pointless and inefficient from a technical point of view. That being said, everyone is of course welcome to suggest translations, send pull requests or even fork the repository to do their own translations. In fact, I would appreciate any input or help on this, because frankly, it is a quite lot of work.

  12. Perfect design choice for this kind of site in my opinion. Puts the focus on her work.

    I wouldn't even change the Vimeo video player, it's perfectly okay in my opinion. However, some small stuff:

    * On "Contact", I'd make the email address clickable or add a contact form. Always make it as easy as possible for people to contact someone.

    * "About" could use some images, if only to reduce the line length.

    * The data for the indivdual screening could use some love. At first glance, I thought she'd had only one screening in 2011 and 2012, respectively. Doesn't really stand out that both years are actually lists of multiple screenings.

  13. Current state of the GitHub repo is 2.2.3. Ryan's pace indeed can be hard to keep up with, and I have been caught up in work lately.

    However, there are a lot of fields which are "empty" simply because the English word is perfectly fine in German as well, for instance "Admin". There's no need to edit those just for the sake of getting the "translated" state.

×
×
  • Create New...