This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] F2003: More ASSOCIATE stuff


On 08/17/2010 09:58 AM, Daniel Kraft wrote:
Tobias Burnus wrote: I also would expect an error for: The same restrictions are valid for INTENT(IN) variables themselves or PARAMETERs, for instance -- so I'd try to implement some general concept of variable definition context in order to unify and fix this. If that's ok, in a seperate patch.

Yes, that's fine. I just wanted to mention it as you talked about using it as actual argument to "INTENT((IN)OUT)" - thus I wanted to make sure this usage case does not get forgotten.


OK, but I have one nit:

+      gfc_error ("'%s' at %L associated to %s can not"
+             " be used in a variable definition context",
+             sym->name,&sym->declared_at,
+             (target->expr_type == EXPR_VARIABLE
+              ? "vector-indexed target" : "expression"));


Can you split this into two gfc_errors? I think we make the live for the translators much easier if we do not use %s + a string.

I wondered about this, myself. My rationale for why I thought it is not too bad was that the expressions inserted are somewhat "complete expressions" specifying "a thing" -- and thus it should be hopefully possible to translate this constructions (or the individual strings).

Translating individual strings without context is difficult - it it might happen that, e.g., "expression" occurs twice. If you then need an article, you might be in trouble, e.g.
"... to an expression ..." vs. "... to a vector-indexed target"
Where to place the article? In the long string you cannot as it is depends on the term which is in "%s". And for "expression" you only can do it if (a) you realize that it is used in the context above and (b) when "expression" is not used elsewhere.


I think in general, we do not give much help to translators with our strings. I think it is possible to annotate the strings and thus helping the translators to understand the terms, e.g. "dummy" or "parameter" might be wrongly interpreted by compiler/computer science translators without Fortran background.

Have a look at gcc/po/gcc.pot to see how it looks from a translator perspective and note (a) how many strings they have to translate (namely 7865), how many terms are used multiple times (i.e. multiple files listed for a single mesgid), and how few strings have a comment above to help the translator (Answer: Essentially none; there are comments [search for "#."] but they are for the programmers and not for the translators). -- I think we should try to improve the translator comments ...

So do you agree with committing when I've split the error message?

Yes.


Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]