kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

OK, I double-checked.  The schematic doesn’t get the mandatory names at all (just 1, 2, 3, 4).  The netlist exporters (at least generic and kicad) write the untranslated version in all lower-case.  The BOM exporters use the generic netlist exporter.

The 4 known fields are hard-coded, so there’s no existing mechanism we could lean on to do the translations for “standard" default fields.  It’d probably be best to store them in English and translate going out to the UI….

Cheers,
Jeff


> On 23 May 2018, at 13:00, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
> You may want to test this just to be sure.  We had a similar issue with
> translating board layer names in the old board file format which created
> a big headache when we implemented the current board file format.
> 
> On 5/23/2018 4:43 AM, Jeff Young wrote:
>> Reference/Value/Footprint/Datasheet are translated only in the UI: the
>> file always uses the English versions.  (Presumably external tools will
>> look at the files, BOMs, netlists, etc.)
>> 
>>> On 23 May 2018, at 00:41, Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>> wrote:
>>> 
>>> Wouldn't translating them defeat the purpose?  I thought the goal was
>>> consistency.  If you translate them, they will be different for each
>>> language and render code like kicost somewhat useless.
>>> 
>>> On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote:
>>>> Yes, the only way to make them translateable is to hard-code these and
>>>> other values into kicad, same as the existing hard-coded fields.
>>>> 
>>>> That would be a good solution for me, having similar to layers a large
>>>> set of predefined fields, being able to name them and enable them at
>>>> will. But storing them in the files as the hard-codes values.
>>>> 
>>>> This means a large change to the code though, at least if we must have
>>>> the enable/disable feature for this, along with creating new custom
>>>> fields. Not even the PCB editor has this yet. 
>>>> 
>>>> Also, I don't think any of the bom exporter plug-ins are localized, and
>>>> at least one of them completely ignores custom fields and adds it own
>>>> instead, regardless of what is in the file.
>>>> 
>>>> Meanwhile my patch does not affect existing installations, does not
>>>> change any BOM, and does not enforce anything and comes in at a whooping
>>>> 3-4 lines of patch in a single file. It will however add 3 lines to two
>>>> dialogs (field editor and symbol editor) for new installations, which
>>>> can be removed, with 6 clicks of the mouse in eeschema. 
>>>> 
>>>> - Kristoffer 
>>>> 
>>>> On Tue, May 22, 2018, 20:01 Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>
>>>> <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>
>>>> <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>> wrote:
>>>> 
>>>>    I can confirm that default fields only get added when the symbol is
>>>>    edited AND the default field’s value is non-empty.  So it doesn’t
>>>>    seem to me that the proposed patch would pollute existing BOMs.  Or
>>>>    am I missing something?
>>>> 
>>>>    Seth’s comment regarding localisation is an issue, though, as we
>>>>    don’t currently translate default fields.
>>>> 
>>>>> On 22 May 2018, at 17:53, Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>>>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>>>>    <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>> 
>>>>> On 5/22/2018 12:43 PM, Jeff Young wrote:
>>>>>>> It should output all fields defined in schematic symbols
>>>>    regardless if
>>>>>>> each optional field is defined in every symbol.  If they are
>>>>    outputting
>>>>>>> anything other than that, I would consider this a bug.
>>>>>> 
>>>>>> I had trouble parsing this.  Are you saying that the list of
>>>>    output fields should be the union of all fields which have a value
>>>>    somewhere (but excluding default fields which are uniformly blank)?
>>>>> 
>>>>> Yes.  It should be the equivalent of a logical OR.  If a field
>>>>    exists in
>>>>> a single symbol, it should get added to the BOM.
>>>>> 
>>>>>> 
>>>>>> As it stands in 5.0, default fields don’t get pushed to symbols
>>>>    unless the symbol is edited.  At that point I’m not sure if they’re
>>>>    all pushed, or only those with values.
>>>>>> 
>>>>> 
>>>>> It used to be that fields only get saved when they are added to the
>>>>> symbol using the edit symbol properties dialog.  That code has
>>>>    changed a
>>>>> lot since it was originally written so I cannot confirm this.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>