On 2013-05-23 09:29, Diggory wrote:

> If you need to change the text then you also need to update the
> translations, or at least check that they're still correct, so I see
> that as a benefit rather than a problem...

Say I have:

gettext("%s: unknown variable at line %s")

Then I want to change the text to:

gettext("%s: not yet known variable at line %s")

I have to find all places where this text is used in the code. Then I also need to updated the translations. If I used a key instead I only need to update all the translations. I don't need to change my code.

-- 
/Jacob Carlborg

On 2013-05-23 10:29, Jacob Carlborg wrote:

> Say I have:
>
> gettext("%s: unknown variable at line %s")
>
> Then I want to change the text to:
>
> gettext("%s: not yet known variable at line %s")
>
> I have to find all places where this text is used in the code. Then I
> also need to updated the translations. If I used a key instead I only
> need to update all the translations. I don't need to change my code.

Also, with the key approach I can just send a separate file to someone else to do the translation, even the English translation. Sure I probably could have a separate file for the English translation as well but that would be duplicating the string.

-- 
/Jacob Carlborg

On Thursday, 23 May 2013 at 08:31:46 UTC, Jacob Carlborg wrote:
> On 2013-05-23 10:29, Jacob Carlborg wrote:
>
>> Say I have:
>>
>> gettext("%s: unknown variable at line %s")
>>
>> Then I want to change the text to:
>>
>> gettext("%s: not yet known variable at line %s")
>>
>> I have to find all places where this text is used in the code. Then I
>> also need to updated the translations. If I used a key instead I only
>> need to update all the translations. I don't need to change my code.
>
> Also, with the key approach I can just send a separate file to someone else to do the translation, even the English translation. Sure I probably could have a separate file for the English translation as well but that would be duplicating the string.

Given a change that is purely aesthetic like that you could just change the english translation instead... Also "find and replace" takes a few seconds...

If you are suggesting to use a named constant as a key, this also suffers from the exact problem you are pointing out that if you need to change the name slightly you need to do it in all places that constant is used in the code.

It also suffers from the fact that unless you use unreasonably long names for the constant you can't easily tell what it contains.

Plus assuming these constants are internally numbered and that is the key used, you get the problem of translations matched to the wrong key and nobody realising because the key does not relate in any way to the meaning. With a text key the only time you reuse a key is if it has the same meaning.

On 2013-05-23 10:45, Diggory wrote:
> Given a change that is purely aesthetic like that you could just change
> the english translation instead... Also "find and replace" takes a few
> seconds...
>
> If you are suggesting to use a named constant as a key, this also
> suffers from the exact problem you are pointing out that if you need to
> change the name slightly you need to do it in all places that constant
> is used in the code.

I'm not suggesting you should change the key at all.

> It also suffers from the fact that unless you use unreasonably long
> names for the constant you can't easily tell what it contains.

Rails uses "nested keys". It's strings that are translated to keys, i.e.:

translate("items.show.title")

Translation file:

en:
  items:
    show:
      title: Foobar

With a bit of magic it becomes:

translate(".title")

See my reply to Nick:

http://forum.dlang.org/thread/vtaufckbpdkpuxyztyoi@forum.dlang.org?page=14#post-knhqji:241uq9:241:40digitalmars.com

> Plus assuming these constants are internally numbered and that is the
> key used, you get the problem of translations matched to the wrong key
> and nobody realising because the key does not relate in any way to the
> meaning. With a text key the only time you reuse a key is if it has the
> same meaning.

No, see above.

-- 
/Jacob Carlborg

On 5/23/13 4:29 AM, Jacob Carlborg wrote:
> On 2013-05-23 09:29, Diggory wrote:
>
>> If you need to change the text then you also need to update the
>> translations, or at least check that they're still correct, so I see
>> that as a benefit rather than a problem...
>
> Say I have:
>
> gettext("%s: unknown variable at line %s")
>
> Then I want to change the text to:
>
> gettext("%s: not yet known variable at line %s")
>
> I have to find all places where this text is used in the code. Then I
> also need to updated the translations. If I used a key instead I only
> need to update all the translations. I don't need to change my code.

enum string unknownVar = "%s: unknown variable at line %s";
... gettext(unknownVar) ...


Andrei

On 5/23/13 4:31 AM, Jacob Carlborg wrote:
> On 2013-05-23 10:29, Jacob Carlborg wrote:
>
>> Say I have:
>>
>> gettext("%s: unknown variable at line %s")
>>
>> Then I want to change the text to:
>>
>> gettext("%s: not yet known variable at line %s")
>>
>> I have to find all places where this text is used in the code. Then I
>> also need to updated the translations. If I used a key instead I only
>> need to update all the translations. I don't need to change my code.
>
> Also, with the key approach I can just send a separate file to someone
> else to do the translation, even the English translation. Sure I
> probably could have a separate file for the English translation as well
> but that would be duplicating the string.

enum string unknownVar = "9b4db58e27bf9fac1be43ed754fbc44c";
... gettext(unknownVar) ...


Andrei

On 2013-05-23 14:56, Andrei Alexandrescu wrote:

> enum string unknownVar = "%s: unknown variable at line %s";
> ... gettext(unknownVar) ...

That's kind of the same thing as using the key approach that Diggory didn't like.

-- 
/Jacob Carlborg

On 23/05/13 17:19, Jacob Carlborg wrote:
> On 2013-05-23 08:27, Peter Williams wrote:
>
>> An example of how I would envisage gettext being used in D is:
>>
>> writefln(gettext("%s: unknown variable at line %s"), filename,
>> linenumber);
>>
>> It is a common practice, to define a macro (or equivalent) _(arg) as an
>> alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because
>> people like brevity.
>>
>> I would suggest using the gettext() functionality for i18n but design
>> the notation used within programs (to access that functionality)
>> according to what best suits the D paradigm.
>
> Is the text you want to translate the actual key?

Yes.

> That sounds very
> stupid. What if I need to change the text?
>

Well. the translation will also need to be changed to any extra id that you'd given the original string is now useless.

Believe me, the give the strings an extra id idea has been tried (many times) and it failed badly (compared to gettext's model).

Peter

On 23/05/13 17:29, Diggory wrote:
>
> What's great about it is you can develop your program with having to
> mess about with keys or anything to do with i18n, just remember to call
> "gettext()" and when your done it's already ready for translations to be
> added. Most other schemes require you to create a key before you can do
> anything which is a massive waste of time while developing when you may
> end up changing it numerous times or end up not even needing it.

Exactly.  From the programmers POV i18n with gettext() is a breeze.

Peter
PS retrofitting i18n using gettext() is equally painless to the point of being boring.

On 23/05/13 16:36, Jacob Carlborg wrote:
> On 2013-05-23 01:51, Peter Williams wrote:
>
>> That is indeed the case.  I avoid all things Apple as my experience has
>> been that they seem to think they still own a device after they've sold
>> it to me.
>
> I can understand that. But if we are to create something like this
> thread suggest I would say that it's almost irresponsible to not try all
> the alternatives. Ok, it might not be that easy to try the Apple stuff,
> need the correct hardware and so on. Yes, there are workarounds as well.

If I had been advocating the banning of GUI builders that would be the case but I was just saying I found them not very useful once I was familiar with the API proper.

>
>> What you describe isn't a very attractive work flow (for me).  Using
>> PyGTK direct I just use normal OOP techniques to extend widget classes
>> and adding a widget to a window is very simple operation (1 statement)
>> and certainly doesn't need a GUI to achieve it.
>
> You will need do the same thing in Xcode as well. What I described here
> was how to add a custom view, that you already have created using
> inheritance, using the GUI builder to a window. I can add as well that
> you're not forced to use the GUI builder, but it's generally easier.

For you maybe.  My experience has been the opposite.  I'm not proposing that you shouldn't be able to use such a tool if that's your preference just that it shouldn't be the only way to create a GUI.

Peter
PS I'm a great believer in GUIs and have spent a great deal of time writing GUI wrappers for tools such a quilt, mercurial and git just to avoid having to type the same thing over and over at the command line. But I always include a mechanism for typing in commands directly as cases always arise where the GUI can't do exactly what you want.